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Preface 


Although  a  lot  of  theory  about  graph  models  has  been 
developed,  relatively  little  work  has  been  directed  to  the 
application  of  graph  model  techniques.  This  report  describes 
the  development  of  a  graph  model  representation  of  the  Digital 
Avionics  Information  System  (DAIS) ,  a  distributed  processor 
computer  architecture.  The  class  of  graph  models  used  in  this 
investigation  are  known  as  Evaluation  nets.  Evaluation  nets 
were  developed  by  Dr.  Gary  Nutt  and  are  one  of  the  few  graph 
model  classes  developed  specifically  to  support  computer  system 
performance  analysis  efforts. 

Thanks  are  due  to  Capt.  Walt  Seward  who  sponsored  this 
Investigation.  Dr.  Gary  Lamont  was  most  helpful  as  my  advisor, 
providing  guidance  and  helping  solve  some  difficult  problems 
during  model  construction.  Special  thanks  are  due  to  Delores 
Lamont  who  spent  many  long  nights  at  her  typewriter  preparing 
the  final  copy  of  this  report.  Most  of  all,  I  am  forever 
grateful  to  my  wife,  Linda.  Without  her  personal  sacrifices 
and  continual  encouragement,  I  would  not  have  completed  this 
project . 
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Abstract 


Three  evaluation  net  graph  models  of  the  Digital  Avionics 
Information  System  (DAIS)  were  constructed.  The  three  models 
represent  three  increasingly  lower  levels  of  detail;  the  third 
model  represents  the  DAIS  at  a  task  flow  level  of  detail.  The 
models  are  evaluated  as  analysis  tools.  Methods  are  presented 
for  analyzing  the  DAIS  structure  and  performance  and  examples 
are  given.  The  biggest  problem  associated  with  a  performance 
analysis  using  evaluation  nets  is  the  recording  of  data 
collected  during  model  analysis.  A  solution  to  the  data 
recording  problem  is  to  utilize  data  automation  techniques. 
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A  GRAPH  MODEL  REPRESENTATION  OF  A 
DISTRIBUTED  PROCESSOR  COMPUTER  SYSTEM 


I  Introduction 


Every  computer  system  is  designed  to  perform  a  certain 
function  or  set  of  functions. i  Whether  or  not  a  system  per¬ 
forms  its  function(s)  and,  J/z  so,  how  well  does  the  system 


perform  its  function(s)  ^e  questions  which  lead  to  a  perform¬ 
ance  evaluation  effort.  The  most  accurate  way  to  evaluate  a 
system’s  performance  is  to  measure  the  system  under  its  real 
workload  (Ref  32:19).  Very  often,  though,  it  is  not  feasible 
or  practical  to  measure  an  existing  system  (Ref  5:12).  When 
the  system  to  be  analyzed  is  not  available  for  direct  analysis, 
a  model  of  the  system  can  serve  as  the  subject  of  analysis,  v 
Even  if  the  system  is  available,  there  are  many  possijaleCad van¬ 


tages  of  analyzing  models  ins 


ie"  real  systems,  such  as 


cost-eJfec-fefySness ,  flexibility,  and  forecasting  (Ref  12:10-11) 

/ 

This  investigation  focuses  on  the  use  of  a  particular  class  of 
graph  models,  known  as  Evaluation-Nets,  to  model  a  distributed 
processor  computer  system  in  support  of  a  performance  analysis 
effort . 
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DAIS 

The  Digital  Avionics  Information  System  (DAIS)  is  a  dis¬ 
tributed  processor  computer  system  developed  for  the  Air  Force 
to  simulate  avionics  computer  systems.  Located  at  the 
Avionics  Lab,  Wright-Patterson  Air  Force  Base,  Ohio,  the  pri¬ 
mary  mission  of  the  DAIS  is  to  provide  a  host  computer  system 
on  which  to  test  and  evaluate  new  or  changes  to  existing  avi¬ 
onics  computer  systems  (Ref  33:1).  The  DAIS  provides  suf¬ 
ficient  modularity  and  redundancy  to  allow  a  user  to  simulate 
all  or  a  subset  of  the  avionics  computer  system’s  functions 
(navigation,  target  acquisition,  flight  plan,  on-board  stores, 
etc.).  Sensors,  analog  devices,  weapons,  and  displays  can  be 
connected  to  the  DAIS  via  a  standardized  multiplexed  data 
bus  system,  MIL-STO-1553A  (Ref  10,30,31). 

At  the  time  of  this  investigation,  the  DAIS  has  not  yet 
been  fully  implemented  (PDP-11/40  computers  are  being  used  to 
simulate  AN/AYK-15  avionics  processors  and  a  DEC-10  computer 
system  is  being  used  to  simulate  the  rest  of  the  DAIS  system 
and  DAIS  environment).  For  a  general  description  of  the  DAIS, 
the  reader  is  directed  to  Chapter  II  of  this  report.  For  a  de¬ 
tailed  description  of  the  DAIS,  the  reader  is  referred  to 
References  1,2,3,9,18,23,  and  25. 

Graph  Models 

A  functional  model  describes  how  a  system  operates  and  can 
be  used  to  derive  a  performance  model  in  support  of  a  perfor¬ 
mance  analysis.  Liba  Svobodova  (Ref  32)  defines  four  classes 
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of  functional  models:  flowchart  models,  parallel  nets,  finite- 
state  models  and  queueing  models  (32:31).  The  first  three 
classes  are  types  of  directed  graph  models  in  which,  generally, 
nodes  represent  tasks  and  arcs  represent  flow  of  control. 

Flowchart  models,  as  the  name  implies,  are  derived  from 
functional  flowcharts  and  pictorally  represent  the  computation¬ 
al  tasks  of  a  system.  Given  the  execution  time  of  the  tasks 
and  the  probability  of  following  different  arcs,  a  simulation 
of  system  execution  can  be  effected  and  analyzed.  However, 
since  Flowchart  models  do  not  provide  the  capability  to  repre¬ 
sent  amounts  and  types  of  resources  or  the  scheduling  of  these 
resources,  Flowchart  models  cannot  be  used  to  represent  a  total 
system,  but  only  the  programs  executed  by  the  processor 
(Ref  32:31). 

Nodes  represent  states  of  the  system  and  arcs  represent 
transitions  between  states  in  a  finite-state  model  (Ref  32:32). 
Since  a  system  state  is  defined  by  the  states  of  the  system 
components,  parallel  processing  can  be  represented  in  a  finite- 
state  model.  At  the  task  level,  though,  the  number  of  possible 
states  of  the  system  can  be  a  large  number.  For  example,  in 
the  DAIS  system,  a  task  can  be  in  any  one  of  six  states  and 
there  are  three  general  classes  of  tasks.  For  a  two  processor, 
two  channel  DAIS  simulation,  a  finite-state  model  of 

(6  x  3  x  2^)  =  288  nodes  would  be  required.  (Addition  of 
just  one  more  processor  and  channel  requires  a  model  with  over 
4600  nodes!)  The  point  here  is  that  finite-state  models  are 
useful  for  high  level  analysis  of  a  system,  but  may  be  quite 
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complex  and  unwieldy  at  a  detailed  task  level. 

Parallel  nets  are  directed  graphs  with  two  types  of 
nodes,  transitions  and  places  (Ref  32:32).  Places  represent 
the  conditions  which  must  be  satisfied  for  a  transition  to  be 
enabled.  Transitions  represent  events  which,  when  enabled, 
may  occur.  Tokens  are  markers  on  places  which  indicate 
whether  or  not  the  corresponding  conditions  are  satisfied 
(a  place  with  a  token  represents  a  satisfied  condition). 

Places  are  only  connected  to  transitions,  and  transitions  are 
only  connected  to  places,  via  arcs.  Since  several  transitions 
may  be  enabled  simultaneously  and  independently,  parallel  nets 
may  describe  concurrent,  asynchronous  processing  (as  in  the 
DAIS).  A  simple  parallel  net  model  is  shown  in  Figure  1.  A 
token,  represented  by  the  solid  black  dot,  resides  on  place 
p3.  This  is  interpreted  as  "CPU  busy",  and  transition  t2  is 
enabled.  When  transition  t2  fires,  t  removes  a  token  from  p^ 

and  places  a  token  on  each  of  the  places  p^  and  p^  (transition 

t^  is  now  enabled) . 

Petri  nets.  Timed  Petri  nets,  Colored  Petri  nets,  and 
Evaluation  nets  are  four  classes  of  directed  graph  models 
that  fall  into  Svobodova's  parallel  net  category  of  func¬ 
tional  models.  Petri  nets  were  used  to  derive  the  latter 
three  classes  of  graph  models  just  mentioned.  Figure  1  could 
be  interpreted  as  a  graph  representation  of  a  Petri  net. 

Properties  of  Petri  nets  which  make  them  useful  for  model¬ 
ing  distributed  processor  systems  are  their  concurrency  or 
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P4 


#  :  token 
PLACES 

PI  :  CPU  idle 
P2  :  Request  for  CPU 
P3  :  CPU  busy 
P4  :  task  complete 
TRANSITIONS 

t^  :  Allocate  CPU 

t2  •  Deallocate  CPU 


Fig.  1  Parallel  Net  Model 


(Ref  32:33) 
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parallelism  and  asynchronous  nature  (Ref  21:229).  However, 
some  properties  of  Petri  nets  limit,  if  not  prevent,  the  use 
of  Petri  nets  for  performance  analysis.  Once  a  transition  is 
enabled  in  a  Petri  net,  the  only  action  guaranteed  is  that  the 
transition  will  fire  within  an  unspecified  but  finite,  future 
time  interval.  In  addition,  the  firing  of  the  transition 
takes  zero  time.  Therefor  it  is  not  possible  to  specify  how 
much  time  is  consumed  by  processes  and  actions  in  a  system. 
Also,  the  tokens  used  in  Petri  nets  are  simple  markers  which 
can  only  be  used  to  indicate  whether  a  place  is  occupied  or 
not.  If  a  token  were  allowed  to  take  on  values,  or  better  yet, 
a  vector  of  values,  then  it  could  be  differentiated  from  other 
tokens.  Such  a  token  could  represent  a  job  and  its  vectored 
requests  for  and  uses  of  modeled  systems  resources  as  the  token 
moved  about  in  the  net. 

Timed  Petri  nets  (Ref  22)  are  an  extension  of  Petri  nets 
which  assign  finite  firing  times  to  the  transitions  in  a  net 
model.  Timed  Petri  nets  can  be  used  to  determine  the  compu¬ 
tation  rates  of  activities  in  a  modeled  system. 

Colored  Petri  nets  (Ref  34)  do  not  assign  finite  firing 
times  to  transition,  but  they  do  provide  a  means  of  resolving 
conflicts  related  to  priority  of  tasks.  Tokens  are  assigned 
colors  which  can  be  used  to  reflect  token  priorities  when 
there  arises  a  conflict  of  several  different  typed  (colors) 
of  tokens  in  an  input  place  of  a  transition  and  one  of  these 
tokens  must  be  selected  to  enable  the  transition. 

Evaluation  nets  (Ref  15)  incorporate  both  finite 
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transition  firing  times  and  tokens  with  vectors  of  values. 
Evaluation  nets  (E-nets)  were  developed  specifically  for  per¬ 
formance  evaluation  studies,  providing  "a  medium  for  graphic¬ 
ally  representing  the  structure  of  systems  composed  of 
asynchronous  events"  (Ref  15:IC).  In  order  to  facilitate  net 
analysis,  a  special  type  of  place  was  introduced,  termed  a 
resolution  location,  which  can  be  used  to  resolve  conflicting 
situations  that  may  arise  in  the  net  (Ref  15:23).  These 
"resolution  locations  provide  a  deterministic  method  to  resolve 
the  conflict  whenever  it  does  appear  during  a  net  operation" 
(Ref  15:24)  which  is  not  available  in  the  Petri  net  or  Timed 
Petri  net  models.  For  a  general  description  of  Evaluation 
nets  the  reader  may  refer  to  Chapter  II  of  this  report.  For 
a  detailed  description  and  discussion  of  the  development  of 
E-nets  and  their  applications,  refer  to  Reference  15. 

Problem  Statement 

It  is  desired  at  the  Air  Force  Avionics  Lab  at  Wright- 
Patterson  AFB  to  have  the  ability  to  perform  a  high  level 
analysis  of  proposed  avionics  computer  systems  without  having 
to  operate  a  real-time  system  (as  will  be  done  with  the  DAIS). 
The  aforementioned  advantages  of  model  analysis  apply  when  a 
model  is  compared  to  a  real-time  hardware  simulation.  The 
purpose  of  this  investigation  is  to  construct  a  graph  model  of 
the  DAIS,  a  distributed  processor  avionics  system,  based  on 
the  class  of  parallel  net  models  known  as  Evaluation  nets. 

After  the  model  is  constructed,  it  will  be  evaluated  as  a  tool 
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for  analyzing  the  performance  of  a  two  processor  DAIS  con¬ 
figuration. 

Scope 

The  intent  of  this  investigation  is  to  use  a  particular 
class  of  graph  models  to  model  a  particular  distributed  pro¬ 
cessor  avionics  computer  system  configuration  in  order  to 
analyze  the  system's  performance.  Evaluation  nets  were  select¬ 
ed  because  they  provide  the  capabilities  (conflict  resolution, 
transition  execution  times,  and  vectored,  valued  tokens)  to 
perform  a  realistic  representation  of  system  operation  and 
characteristics  (concurrent,  asynchronous  processing). 
Additionally,  E-nets  provide  mechanisms  for  model-environment 
communication  (see  Chapter  II)  which  facilitate  net  model  ex¬ 
ecution.  Since  the  distributed  processor  avionics  systems 
which  the  DAIS  is  intended  to  simulate  do  not  exist  yet,  the 
DAIS  itself  will  be  modeled.  Analysis  of  the  model  can  re¬ 
veal  anv  bottlenecks  in  the  system  and  provide  statistical 
data  on  task  assignment  and  execution. 

Constraints  and  Assumptions 

Constraints  and  assumptions  are  discussed  together  since 
they  are  closely  connected.  Probably  the  biggest  constraint 
on  the  modeling  effort  was  the  unavailability  of  detailed  doc¬ 
umentation  on  the  Master  Executive.  The  Master  Executive  is 
the  part  of  the  DAIS  operating  system  responsible  for  overall 
system  control  and  data  bus  communications  control.  Many 
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assumptions  concerning  Master  Executive  functions  were  made 
which  cannot  be  verified  or  faulted  until  the  said  documenta¬ 
tion  is  available  (Ref  28.29).  These  assumptions  are  dis¬ 
cussed  in  Chapter  III,  where  they  can  be  discussed  in  context 
with  their  impact  on  the  derived  model. 

Approach 

The  investigation  proceeded  in  a  top-down  manner.  Prior 
to  constructing  any  E-net  graphs,  a  set  of  guidelines  were 
established.  As  of  the  writing  of  this  report,  only  one  con¬ 
figuration  has  been  simulated  at  the  Avionics  Lab,  that  being 
a  two-processor  configuration  of  an  attack  aircraft  avionics 
computer  system  (Ref  19:24).  This  was  the  configuration  chosen 
for  the  E-net  modeling  effort. 

Three  E-net  graph  models  were  constructed  which  represent¬ 
ed  the  functional  relationship  of  the  two  processors,  their 
bus  interface  units,  and  the  data  bus.  The  three  models  repre¬ 
sent  successively  greater  levels  of  detail  of  the  DAIS.  The 
third  model  represents  the  DAIS  at  a  task  level,  and  was  eval¬ 
uated  as  a  tool  for  analyzing  the  DAIS. 

Organization 

Chapter  II  contains  a  general  description  of  the  DAIS  and 
Evaluation-nets.  In  Chapter  III  the  E-net  models  are  presented 
with  a  discussion  of  the  model  construction  effort.  A  discus¬ 
sion  of  the  analysis  effort  is  presented  in  Chapter  IV.  Results 
of  the  investigation  and  some  concluding  remarks  evaluating  this 
undertaking  are  presented  in  Chapter  V.  Finally,  some  recom¬ 
mendations  for  future  work  are  made. 
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II  Background 


A  general  description  of  the  architecture  and  theory  of 
operation  of  the  DAIS  and  an  informal  description  of  E-nets  is 
presented  in  this  chapter.  Enough  detail  on  the  DAIS  is  pre¬ 
sented  in  this  chapter  to  give  the  reader  a  basic  understanding 
of  the  DAIS  structure  and  operation;  more  detailed  discussions 
of  some  portions  of  the  architecture  and  operation  are  present¬ 
ed  in  Chapter  III  to  explain  the  configuration  of  some  parts  of 
the  E-net  graphs  presented  there.  Only  a  definition  of  E-nets 
is  presented  in  this  chapter.  For  a  formal  discussion  of  the 
development  and  underlying  theory  of  E-nets  and  some  examples 
of  their  application  to  problems  in  the  field  of  computer 
science,  the  reader  is  referred  to  Reference  15. 

DAIS 

Generally,  an  avionics  system  is  a  collection  of  separate, 
and  usually  dissimilar,  specialized  systems  which  communicate 
through  specialized  interfaces.  Each  major  avionics  function 
(e.g.  navigation,  communications,  weapon  delivery,  flight  con¬ 
trol,  and  stores  management)  is  supported  by  its  own  special¬ 
ized  computer  system.  A  request  for  navigation  data  by  the 
flight  control  function  necessitates  a  specialized  interface 
to  support  the  data  transfer.  As  can  be  imagined,  there  are 
numerous  dissimilar  computer  systems  and  interfaces  being 
maintained  by  the  Air  Force  in  support  of  the  various  aircraft 
and  missions  being  flown. 
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DAIS  Concept.  "The  purpose  of  the  DAIS  concept  is  to  re¬ 


duce  proliferation  and  nonstandardization  of  aircraft  avionics, 
and  permit  the  Air  Force  to  assume  initiative  in  the  specifi¬ 
cation  of  standard  avionic  systems  and  interfaces  for  future 
Air  Force  system  acquisitions.  The  DAIS  concept  proposes  that 
the  processing,  information  transfer,  control  and  display  func¬ 
tions  be  common  and  service  all  the  previously  described  func¬ 
tional  areas  on  an  integrated  basis"  (Ref  23:5).  This  total 
system  concept  is  to  be  realized  by  incorporating  into  the 
DAIS  design  such  features  as  standardization,  modularization, 
and  redundancy.  Table  1  lists  the  DAIS  objectives  along  with 
the  corresponding  design  considerations  to  meet  the  objectives. 

General  Description.  A  DAIS  configuration  is  composed  of 
hardware  and  software  building  blocks  or  core  elements.  The 
hardware  core  elements  are  the  multiplex  bus  system  (Bus  Con¬ 
trollers,  Remote  Terminals,  and  Data  Bus),  the  processors 
(with  associated  memory),  and  the  controls  and  displays  (pilot 
interface).  Software  core  elements  are  the  Operational  Flight 
Program  (OFP)  and  the  Operational  Test  Program  (OTP)  (Ref  23:5). 
Additional  avionics  system  elements  (sensors,  weapons,  etc.) 
are  interfaced  to  the  Data  Bus  via  Remote  Terminals  or,  if 
they  are  compatible  with  the  multiplex  bus  protocol  (Ref  31), 
connected  directly  to  the  Data  Bus.  Figure  2  is  a  functional 
diagram  of  a  DAIS  configuration.  The  number  of  processors 
and  the  number  and  types  of  avionics  controls  and  displays, 
weapons,  sensors,  and  communications  would  be  dependent  on  the 
type  of  aircraft  and  its  mission  and  would  be  specified  by  the 
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Table  I  Design  Considerations  Utilized  in 

Meeting  DAIS  Objectives 

DAIS  Objectives 

Design  Considerations 

Reduce  Unnecessary 

Replication  (Core  Elements) 

Development  Prolifer¬ 
ation 

Standardization 

Improve  Operational 

Automated  Aids 

Efficiency  and 

Digital  Technology 

Availability/ 

Redundancy  Utilization 

Maintainability 

On-board  Test 

Improve  Flexibility 

Functional  Modularity 

to  Changes 

System  Modularity 

Maintain  Basic 

Proven  Technology 

Avionics  Performance 

(Ref  23:6  ) 


systems  designer. 

Architecture .  The  DAIS  is  structured  as  a  federated  net¬ 
work  (each  processor  only  has  direct  access  to  its  own  assoc¬ 
iated  memory).  A  MIL-STD-1553A  standardized  time  division 
multiplex  data  bus  provides  dual  redundant  communication  paths 
between  system  core  elements  (and  any  bus-compatible  avionics 
elements).  The  architecture  is  designed  for  application  to  a 
broad  class  of  configurations  where  the  number  of  processors 
can  be  increased  or  decreased  based  on  mission  processing  re¬ 
quirements.  Figure  3  shows  a  general  DAIS  system  architecture. 

The  DAIS  processors  are  general  purpose  digital  mini¬ 
computers  specially  engineered  for  airborne  use.  Operational 
features  include  a  vectored  interrupt  priority  system,  interval 
timers,  floating  point  arithmetic,  and  379K  operations  per 
second  throughput  (based  upon  a  specified  benchmark  program). 

Up  to  65K  words  of  memory  in  16K  word  modules  is  available, 
all  of  which  is  directly  addressable.  Input  and  output 
features  include  discretes,  program  control,  direct  memory 
access  (DMA),  and  external  interrupts  (Ref  23:15-18). 

Associated  with  each  processor  in  a  DAIS  configuration  is 
a  Bus  Control  Interface  Unit  (BCIU).  A  separate  port  to  memory 
is  provided  for  the  BCIU  via  a  DMA  channel.  Functionally,  the 
BCIU  is  an  extension  of  the  processor's  I/O  capability  and 
serves  as  an  interface  between  the  processor  and  the  data  bus. 
Figure  4  illustrates  the  major  components  of  a  BCIU.  Timing, 
control,  instruction  decoding,  and  data  transfer  routing  is 
provided  by  the  Bus  Control  Module  (BCM),  a  16-bit 


microprogrammed  controller  with  a  1024  word  by  72  bit  control 
memory  and  a  32-word  general  register  set.  Each  Multiplex 
Terminal  Unit  (MTU)  interfaces  the  BCM  to  one  of  the  dual  re¬ 
dundant  data  buses,  and  contains  the  transmitter  and  receiver 
circuits,  as  well  as  the  logic,  to  operate  the  1.0  mbs  data 
bus.  The  Processor  Interface  Module  (PIM)  contains  the  input/ 
output  interfaces  for  communications  with  the  associated  pro¬ 
cessor.  The  PIM  has  programmed  input/output  (PIO),  direct 
memory  access  (DMA) ,  and  interrupt  capabilities  with  the  pro¬ 
cessor  . 

A  Remote  Terminal  (RT)  provides  the  interface  between  the 
dual  multiplex  buses  and  a  subsystem.  The  RT  transfers  data 
in  both  directions  on  the  Data  Bus  based  on  commands  received 
from  either  bus,  and  provides  status  replies  in  response  to 
commands.  The  RT  partitions  messages  to  the  appropriate  sub 
systems  it  services  and  conditions  the  signals  to  (from)  the 
different  subsystems  from  (to)  the  Data  Bus.  The  major  sub- 
modules  of  an  RT  can  be  seen  in  Figure  5.  Each  Multiplex 
Terminal  Unit  (MTU),  interfaces  to  one  data  bus,  transmitting 
and  receiving  information  between  the  bus  and  a  Timing  and 
Control  Unit  (TCU) .  The  TCU  performs  all  of  the  timing,  con¬ 
trol,  buffering,  decoding,  and  checking  required  to  transfer 
information  between  the  MTU  and  the  Interface  Modules  (IM). 
Each  IM  will  interface  the  TCU  to  a  particular  subsystem  de¬ 
vice  (e.g.  a  raster  display,  aircraft  attitude  sensor,  com¬ 
munication  device).  A  standard  set  of  IM  types  is  available 
for  interfacing  the  various  types  of  signals  possible  from 
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various  subsystems.  Any  type  of  IM  can  fit  in  any  IM  slot 
in  an  RT.  The  number  and  types  of  IMs  contained  in  a  partic¬ 
ular  RT  depends  on  the  subsystems  serviced  by  the  RT  as  spec¬ 
ified  by  the  systems  designer. 

Software .  The  OFP  software  package  is  resident  within 
the  processors  and  can  be  broken  down  into  two  major  parts: 
the  Executive  Software  and  the  Applications  Software.  The 
Executive  Software  serves  as  the  operating  system,  and  is 
mission  and  aircraft  invariant.  The  Applications  Software 
changes  from  mission  to  mission,  from  aircraft  to  aircraft, 
or  as  sensors,  weapons,  and  subsystems  vary.  The  OTP  contains 
software  for  use  on  the  ground  (on  board  the  aircraft)  to 
isolate  avionics  systems  failures  at  the  Line  Replaceable 
Unit  (LRU)  levels.  In  support  of  the  DAIS  objectives,  the 
mission  software  is  characterized  by  top  down  structured 
design,  modularization,  flexibility  to  modifications,  and 
portability. 

Executive .  The  Executive  Software  is  further  broken  down 
into  two  functional  parts:  the  Master  Executive  and  the  Local 
Executive.  The  Master  Executive  is  responsible  for  overall 
system  control  and  resides  in  the  processor  designated  the 
Master  Processor.  The  Master  Processor  is  given  responsibil¬ 
ity  for  control  and  servicing  of  the  Data  Bus.  The  Master 
Executive  can  also  reside  in  a  processor  designated  the 
Monitor,  which  provides  a  back-up  to  the  Master  Executive. 

The  Local  Executive  is  resident  in  the  Master  Processor  and 
all  other  processors  (termed  Remote  Processors).  The  Local 
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Executive  provides  real-time  services,  data  input  and  output, 
interrupt  handling,  and  task  control  to  the  Applications 
Software.  Figure  6  shows  a  functional  breakdown  of  the  DAIS 
Executive  Software.  System  Initialization  and  System  Control 
are  dependent  on  the  actual  system  and  operating  procedures 
used,  and  on  Master  recovery,  respectively.  Figure  7  shows 
the  physical  breakdown  of  the  Executive  Software  in  the  proces¬ 
sors  . 


The  Master  Executive  is  table  driven  and  manages  the 
system  configuration  by  performing,  as  a  minimum,  the  follow¬ 
ing  functions  (Ref  23:20-21): 

1)  Data  Bus  Control  -  controls  transmission  of  synchro¬ 
nous  and  asynchronous  messages  over  the  multiplexed 
data  bus . 

2)  System  Synchronization  Control  -  allocates  time 
segments  (minor  cycle  and  major  cycle)  for  synchro¬ 
nous  messages  and  performs  minor  cycle  synchroniza¬ 
tion  by  transmitting  master  function  mode  commands 
to  the  other  processors. 

3)  System  Error  Management  -  monitors  and  analyzes  errors 
and  failures  based  upon  both  bus  and  terminal  devices. 
Initiates  message  retry  procedures  to  recover  from 
message  errors. 

4)  Configuration  Management  -  detects  and  isolates  per¬ 
manent  device  failures,  maintains  system  configura¬ 
tion  status,  reports  failure  to  the  application  soft¬ 
ware,  and  initiates  backup  or  recovery  operation  if 
required. 

5)  Mass  Memory  Management  -  provides  for  retrieving  and 
storing  information  from  the  mass  memory  on  request. 

The  Local  Executive  is  identical  in  each  processor  and  is 
only  responsible  for  those  activities  in  its  own  CPU.  In  mana¬ 
ging  all  activities  within  a  processor  the  Local  Executive  per¬ 
forms,  as  a  minimum,  the  following  functions  (Ref  23:20): 
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1)  Process  Control  -  provides  services  for  the  Applica¬ 
tions  Software  to  activate  and  deactivate  periodic 
and  non-periodic  tasks  when  appropriate  conditions 
have  been  met.  The  conditions  shall  be  based  upon 
logical  setting  (on  or  off)  of  real  time  events. 

2)  Event  Control  -  provides  the  mechanism  for  setting, 
resetting,  and  evaluating  real  time  events  which 
communicate  conditions  (on  or  off)  signaled  between 
tasks  whether  in  the  same  or  different  processors. 

3)  Data  Control  -  guarantees  integrity  of  shared  data 
and  provides  mechanism  for  transmission  and  recep¬ 
tion  of  data  over  the  multiplex  bus. 

4)  Processor  Initialization  -  provides  initialization 
for  processor  power  transient  recovery,  initial  pro¬ 
gram  load,  and  minor  cycle  synchronization  with  the 
other  processors. 

Applications  Software.  The  Applications  Software  can  be 
broken  down  into  more  basic  blocks:  Compool  blocks,  Tasks,  Com- 
subs ,  and  Events  (Ref  33:3).  Compool  blocks  contain  the  global 
data  and  are  centrally  defined  and  controlled.  Tasks  are  the 
real-time  processes  within  the  system.  Comsubs  are  commonly 
used  subroutines  that  perform  calculations  only,  have  no  real¬ 
time  control  or  interaction,  and  communicate  solely  through 
parameter  passage  (no  access  to  Compool  blocks).  Events  are 
units  of  binary  valued  information  that  enable  tasks  and  the 
environment  to  interact  (Ref  33:3). 

The  DAIS  Executive  is  priority  driven.  The  Task  with  the 
highest  priority  which  is  capable  of  execution  obtains  the  pro¬ 
cessor.  A  given  Task  must  declare  the  Tasks  to  which  it  refers, 
the  Events  it  uses,  the  Comsubs  it  uses,  and  any  Compool  data 
referred  to  (Ref  33:3). 

The  Applications  Software  implements  the  specific  mission 
avionics  functions  (e.g.  navigation,  weapon  control,  flight 
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plan,  etc.)*  The  Applications  Software  consists  of  tasks  to 
control  the  various  mission  dependent  sensors  (e.g.  navigation 
aids,  communications,  radar  and  subsystems  (e.g.  weapons),  and 
perform  the  various  mission  functions  mentioned  above.  The 
Applications  software  is  organized  in  a  heirarchical  control 
tree  structure  as  seen  in  Figure  8.  All  Applications  Software 
functions  are  either  controllers  or  calculators.  Each  calcu¬ 
lator  is  controlled  by  a  unique  controller  (with  the  exception 
of  common  service  routines).  A  module  (as  represented  by  a 
node  in  the  tree  in  Figure  8)  can  only  invoke  modules  in  its 
own  level  or  itself.  However,  the  events  on  which  activation 
of  a  module  is  based  can  be  signalled  by  modules  at  other 
levels  (Ref  20:22). 

The  functional  categories  of  task  modules  in  the  Applica¬ 
tions  Software  are  seen  in  Figure  9  and  specified  as  follows 
(Ref  18:10-12): 

1)  The  Master  Sequencer  -  is  at  the  top  of  the  Applica¬ 
tions  Software  hierarchy  and  controls  the  request 
processor,  configurator,  and  subsystem  status  mon¬ 
itor.  The  Master  Sequencer  is  only  required  in  the 
Master  and  Monitor  processors. 

2)  The  Request  Processor  -  responds  to  pilot's  requests 
and  invokes  the  appropriate  application  functions 

to  generate  information  for  displays  or  to  control 
avionic  support  subsystems. 

3)  The  Configurator  - 

a)  Defines  the  set  of  application  functions  to 
be  invoked  by  request  from  the  Request  Pro¬ 
cessor  or  the  Subsystem  Status  Monitor. 

b)  Enables  a  new  set  of  available  functions  upon 
significant  changes  in  mission  phasing  or  equip¬ 
ment  moding.  This  set  of  functions  is  based 

on  a  global  knowledge  of  overall  system  status. 
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Fig.  8  Hierarchical  Control  Structure 
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Application  Software  Tree  (Ref  23:98) 


4)  The  Subsystem  Status  Monitor  -  monitors  subsystem 
failures  and  communicates  the  information  to  the 
Configurator. 

5)  Mission  Operations  (OPS): 

a)  Act  as  a  control  authority  for  operations 
either  when  invoked  by  phase  selection  by  the 
pilot  or  automatically  when  current  phases  are 
terminated  in  an  emergency  or  abnormal  condi¬ 
tion. 

b)  Exist,  as  a  minimum,  for  preflight/inf light 
startup,  take-off,  cruise,  weapon  delivery, 
approach  landing,  and  postflight  shutdown 
operations . 

6)  Specialist  Functions  (SPECS)  -  provide  functions  re¬ 
quired  by  OPS  modules  or  by  the  pilot  (e.g.  naviga¬ 
tion,  weapon  test,  etc.). 

7)  Equipment  Handlers  (EQUIPs)  -  exist  for  each  piece 
of  equipment  (e.g.  communication,  radar,  etc.), 
translating  the  data  formats  as  required  for  each 
equipment  and  managing  the  control  mode  of  the 
equipment. 

8)  Display  Processors  (DISPs)  -  provide  data  interface 
and  control  functions  in  order  to  manage  display 
presentations,  such  as  messages,  symbols,  and 
graphical  displays  on  the  DAIS  controls  and  displays. 

9)  The  Integrated  Multifunction  Keyboard  (IMFK)  Handler- 
receives  and  interprets  the  pilot-selected  IMFK  keyed 
information. 

10)  The  Multifunction  Keyboard  (MFK)  Handler  -  is  similar 
to  the  IMFK  Handler  and  acts  as  a  backup  in  the  event 
of  a  IMFK  failure. 

Normal  Operation.  The  DAIS  is  a  real-time ’ system  in  which 
the  Applications  Software  processes  are  coordinated  with  the 
passage  of  real-time  in  the  DAIS  environment.  Timing  within 
the  DAIS  is  specified  in  terms  of  minor  cycles  and  major  frames. 
A  minor  cycle  is  the  time  required  to  execute  the  shortest  syn¬ 
chronous  action  and  a  major  frame  is  the  longest  interval  of  a 


synchronous  action  by  the  Executive.  The  number  of  minor 
cycles  per  major  frame  is  determined  by  the  applications 
programmer  and  is  fixed  upon  system  initialization.  It  is 
possible  to  specify  the  time  of  an  action  within  one  minor 
cycle.  I/O  interactions,  interprocessor  interactions,  and 
task  interactions  may  occur,  may  be  known,  and  may  be  con¬ 
trolled  within  the  framework  of  the  minor  cycle  time 
granularity  (Ref  25:5-6).  Minor  cycle  synchronization  is  used 
to  coordinate  the  actions  of  all  processors. 

The  beginning  of  a  minor  cycle  is  signaled  by  a  timer 
interrupt  (time  A  interrupt)  in  the  Master  Processor.  If 
the  current  minor  cycle's  synchronous  bus  message  list  has 
been  transmitted,  then  the  Master  Executive  starts  the  minor 
cycle  bus  message  list  for  the  new  minor  cycle.  The  minor 
cycle  bus  list  is  a  bus  message  list  of  minor  cycle  interrupts 
to  each  Local  Executive  (Ref  9:51-53).  Upon  receipt  of  the 
interrupt,  the  Local  Executive  calls  the  Minor  Cycle  Setup 
Routine  which  performs  several  functions:  a)  schedules  Tasks 
to  be  executed  during  the  new  minor  cycle,  b)  sets  DMA  point¬ 
ers  to  the  appropriate  message  receive  and  transmit  blocks, 
and  c)  in  the  Master  Processor,  the  Master  Executive  is 
called  to  start  processing  the  synchronous  bus  message  list 
for  the  new  minor  cycle  (Ref  26:144-156). 

Bus  Control .  Bus  control  operations  form  the 
heart  of  the  system  (Ref  9:40).  The  Master  Processor 
and  its  BCIU  control  bus  protocol  and  data  flow  on  the  bus. 
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An  example  of  synchronous  messages  is  the  transfer  of  inertial 
navigation  system  output  data  from  a  Remote  Terminal  to  a  navi¬ 
gation  applications  function  in  a  processor.  Synchronous  mess¬ 
age  operations  attend  to  the  predetermined,  scheduled  flow  of 
data.  A  synchronous  message  is  assigned  a  period  and  phase; 
the  period  is  the  number  of  minor  cycles  between  message  trans¬ 
missions,  and  the  phase  is  the  displacement,  in  minor  cycles, 
relative  to  the  first  minor  cycle  (Ref  9:51).  Asynchronous 
message  operations  manage  the  data  flow  which  cannot  be 
scheduled  in  advance.  An  example  of  an  asynchronous  message 
is  a  request  from  the  pilot,  via  a  Remote  Terminal,  for  a  read¬ 
out  of  the  distance  to  target. 

Synchronous  bus  messages  are  controlled  by  a  predefined 
bus  instruction  list  which  is  part  of  the  Master  Executive’s 
preloaded  tables.  Each  minor  cycle,  the  particular  subset  of 
synchronous  messages  to  be  transmitted  during  that  cycle  are 
linked  to  the  Master  BCIU's  list  of  pending  bus  messages. 
Asynchronous  messages,  which  are  also  predefined,  are  sche¬ 
duled  by  the  Master  Executive  in  response  to  requests  from 
Remote  Terminals  and  applications  tasks  within  the  processors. 
In  general,  asynchronous  message  operations  are  given  priority 
over  synchronous  operations  (Ref  9:42). 

All  Remote  BCIUs  (in  conjuction  with  their  connected 
processors),  Remote  Terminals,  and  bus-compatible  avionics 
subsystems  are  considered  as  Remote  Devices.  Every  bus  oper¬ 
ation  is  initiated  by  the  Master  BCIU  under  control  of  the 
Master  Processor.  The  Master  BCIU  places  a  command  on  the  bus 
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lines  and  then  monitors  the  bus  for  a  status  response  by  the 
Remote  Device.  A  Remote  Device  monitors  the  bus  for  commands 
directed  to  it.  Upon  detecting  a  command  addressed  to  itself, 
the  Remote  Device  responds  by  performing  the  operation  and 
then  placing  a  status  word  on  the  bus  lines.  By  setting 
selective  bits  in  the  status  word,  the  Remote  Device  can  re¬ 
quest  services  from  the  Master  Processor/BCIU  or  inform  the 
Master  Executive  of  a  detected  failure. 

Some  bus  operations,  such  as  transmission  and  reception 
of  synchronous  messages,  require  no  intervention  by  the  proces¬ 
sor.  The  BCIU  uses  DMA  to  transfer  the  data  to  (from)  the 
processor  from  (to)  the  bus.  Asnychronous  bus  operations  are 
among  those  bus  operations  which  require  the  BCIU  to  interrupt 
its  processor  in  order  that  the  Local  Executive  can  process 
the  interrupt  and  take  appropriate  action. 

Task  Control.  Tasks  and  Comsubs  are  the  processing 
modules  of  the  Applications  Software.  Real-Time  Statements 
and  Real-Time  Built-In  Functions  are  used  by  Tasks  to  invoke 
Local  Executive  services  to  control  and  reference  the  state  of 
other  Tasks  and  the  values  of  Events  and  Compool  Block  data 
(Ref  25:9).  To  understand  how  Tasks  interact,  it  is  necessary 
to  understand  the  possible  states  a  Task  may  be  in.  Each 
Applications  Software  Task  is  in  one  of  the  states  shown  in 
Figure  10  at  any  given  instant  in  real  time.  Not  all  states 
are  mutually  exclusive.  A  SUSPENDED  task  is  also  INVOKED, 
ACTIVE,  and  DISPATCHABLE .  The  Real-Time  Statements  SCHEDULE, 
WAIT,  CANCEL,  and  TERMINATE  are  used  by  Tasks  to  change  the 
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Fig.  10  Task  State  Transition  Diagram  (Ref  25:10) 
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states  of  other  Tasks  (or  themselves  in  some  cases). 

Associated  with  each  Task  is  an  Event  Condition  Set. 

The  Event  Condition  Set  is  a  set  of  Conditions,  each  of  which 
is  associated  with  one  or  more  Events.  Dependent  on  the 
occurrence  of  these  Events,  each  Condition  has  a  value  of  ON 
or  OFF.  The  "desired  value"  of  the  Condition  may  be  either  ON 
or  OFF,  and  when  all  the  Conditions  in  an  Event  Condition  Set 
have  their  respective  "desired  values",  the  associated  Task  is 
ACTIVATED  by  the  Executive  (Ref  25:11-18). 

A  Task  returns  from  the  ACTIVE  state  to  the  INACTIVE 
state  for  one  of  two  reasons:  a)  it  completes  execution  or 
b)  another  task  forcibly  TERMINATES  it.  In  either  case, 
immediately  after  being  placed  in  the  INVOKED/INACTIVE  state, 
the  Task's  Event  Condition  Set  is  evaluated,  and  if  all  Con¬ 
ditions  have  their  desired  values,  the  Task  is  immediately 
ACTIVATED  (Ref  25:11). 

A  Task  that  is  ACTIVATED  is  immediately  put  to  the  DIS- 
PATCHABLE  state.  All  DISPATCHABLE  Tasks  are  capable  of  being 
executed.  Whenever  the  Executive  passes  control  to  the  Appli¬ 
cations  Software,  the  DISPATCHABLE  Task  with  the  highest 
priority  is  selected  and  executed.  Once  a  Task  is  in  the 
ACTIVE /DISPATCHABLE /EXECUTING  state,  one  of  three  things  can 
happen  to  it:  a)  it  completes  execution  and  goes  to  the 
INACTIVE  state  (see  above),  b)  a  higher  priority  Task  becomes 
DISPATCHABLE,  and  the  currently  executing  Task  is  SUSPENDED, 
or  c)  the  Task  executes  a  WAIT  statement  (which  specifies  a 
desired  value  for  an  Event  or  a  future  time),  which  causes 
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the  Executive  to  place  the  Task  in  the  WAITING  state.  When 
the  waited-for  condition  is  satisfied,  a  WAITING  Task  is 
again  made  DISPATCHABLE.  A  WAITING  or  SUSPENDED  Task  may  be 
CANCELED  or  TERMINATED  by  another  Task. 

At  any  time,  there  may  be  many  processes  potentially 
executable  within  a  processor  (Ref  25:12).  These  processes 
include  Tasks,  and  Executive  actions  invoked  by  Tasks  in  other 
processors  or  in  response  to  an  RT-generated  request.  A  system 
of  priorities  exists  to  resolve  these  conflicting  demands  for 
the  processor.  There  are  two  classes  of  Tasks:  Normal  Mode 
Tasks  and  Privileged  Mode  Tasks.  As  a  group,  Privileged 
Mode  Tasks  and  Executive  actions  have  higher  priority  than 
Normal  Mode  Tasks  (Ref  25:12). 

Once  a  Privileged  Mode  Task  or  an  Executive  process 
starts  executing,  it  runs  to  completion.  If  an  Executive 
action  is  invoked  by  an  executing  Privileged  Mode  Task  or 
Executive  Process,  the  invoked  process  is  executed  as  if  it 
were  an  inline  block  of  code.  A  Privileged  Mode  Task  or  an 
Executive  process  cannot  be  interrupted  by  a  Task  or  Executive 
action  requested  or  invoked  outside  of  itself  (Ref  25:12). 

When  no  Privileged  Mode  Task  is  ACTIVE  and  no  Executive  action 
is  pending,  the  highest  priority  DISPATCHABLE  Normal  Mode 
Task  is  executed. 

Theoretically,  Normal  Mode  Tasks  are  linearly  ordered  by 
priority  while  Privileged  Mode  Tasks  are  executed  on  a  First- 
come-f irst-serve  basis.  In  actuality,  there  exists  within 
each  processor  a  table  of  entries,  one  for  each  Task,  for  all 
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of  the  Applications  Tasks  (Normal  and  Privileged  Modes)  re¬ 
siding  within  the  processor.  This  table,  named  Task  Table  B, 
is  ordered  by  priority,  with  Privileged  Mode  Tasks  first,  and 
the  lowest  priority  Normal  Mode  Task  last  (Ref  26:21).  The 
relative  order  of  the  Privileged  Mode  Tasks  is  arbitrary,  but 
fixed  at  compilation  time. 

Immediately  following  system  initialization,  one  Task,  the 
Master  Sequencer,  is  INVOKED  by  the  Executive,  while  all  other 
Tasks  remain  in  the  UNINVOKED  state  (Ref  25:11).  Thereafter, 
any  Task  may  be  INVOKED  by  a  schedule  statement  or  UNINVOKED 
by  a  CANCEL  statement  executed  by  another  TASK. 

Summary .  The  Digital  Avionics  Information  System  (DAIS) 
is  a  distributed  processor  avionics  computer  system.  The 
major  hardware  elements  are  the  multiplex  bus  system  (Bus  Con¬ 
trollers,  Remote  Terminals,  and  Data  Bus),  the  processors  (with 
associated  memory),  and  the  controls  and  displays  (pilot  inter¬ 
face).  Additional  avionics  system  elements  (sensors,  weapons, 
etc.)  are  interfaced  to  the  DAIS  system  through  Remote  Terminals 
attached  to  the  Data  Bus  or  through  direct  attachment  to  the 
bus.  The  major  software  elements  of  the  DAIS  are  the  Opera¬ 
tional  Flight  Program  (OFP)  and  the  Operational  Test  Program 
(OTP).  The  OFP  has  two  major  parts,  the  Executive  and  Appli¬ 
cations  Software.  The  Executive  serves  as  the  operating  sy¬ 
stem,  providing  overall  system  control,  bus  control,  and  real¬ 
time  services  to  the  Applications  Software.  The  Applications 
Software  implements  the  avionics  functions  (e.g.  navigation, 
weapon  control,  flight  plan,  etc.),  and  can  be  thought  of  as 


the  user  tasks  serviced  by  the  Executive.  The  Applications 
Software  is  structured  as  a  hierarchical  control  tree  with 
tasks  at  the  nodes.  The  topmost  task  in  the  hierarchy,  the 
Master  Sequencer,  is  scheduled  immediately  following  system 
initialization.  Thereafter,  tasks  are  executed  after  they  are 
scheduled  bv  the  task  immediately  above  them  (and,  of  course, 
in  line)  in  the  control  tree  structure  (see  Figure  8).  The 
OPT  is  composed  of  software  used  on  the  ground  to  isolate 
avionics  system  failures. 
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Evaluation  Nets 


The  remainder  of  this  chapter  is  devoted  to  the  defini¬ 
tion  of  Evaluation  nets  (E-nets).  The  axioms  and  definitions 
presented  are  from  the  formal  definition  of  E-nets  in 
Reference  15.  Several  axioms  and  definitions  are  presented 
which  lead  to  the  formal  E-net  definition  presented  near  the 
end  of  this  section.  An  example  of  the  use  of  E-nets  to  model 
a  simple  computer  system  is  provided  and  will  be  referred  to 
repeatedly.  First,  a  basic  definition  of  E-nets  is  developed. 
Next,  the  concept  of  "net  flow"  is  discussed  and  defined. 

Then,  the  formal  E-net  definition  is  developed  and  presented. 
Lastly,  the  concept  of  "macro  structures"  is  introduced  and 
an  example  of  a  macro  structure  is  presented. 

Basic  Definition!  E-nets  are  characterized  as  marked 
interpreted  directed  graphs  (Ref  15:1b).  An  E-net  is  composed 
of  two  sets  of  nodes,  transitions  and  locations,  interconnec¬ 
ted  by  "directed"  arcs .  Transitions  are  only  connected  to 
locations  and  locations  are  only  connected  to  transitions  via 
arcs  directed  into  or  out  of  the  nodes.  In  Figure  11,  loca¬ 
tion  b^  is  an  input  location  to  transition  a^  and  location  b2 

is  an  output  location  of  a^,  as  evidenced  by  the  directed  arcs 
connecting  these  nodes. 
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The  structure  of  a  parallel  system  can  be  pictorally  re¬ 
presented  by  an  E-net  graph.  The  transitions  represent  events 
or  actions  in  the  system  and  the  locations  represent  conditions 
which  exist  in  the  system.  A  transition  action  causes  the 
status  of  the  locations  (and,  thus,  the  conditions  they  repre¬ 
sent)  attached  to  the  transition  to  be  altered  according  to 
the  particular  transition  definition  (Ref  15:30).  A  token  is 
a  marker  which  may  reside  on  a  location  and  indicated  the 
status  of  the  location  (Ref  15:30).  The  placement  of  a  token 
on  a  location  represents  a  corresponding  condition  which  is 
satisfied.  An  E-net  with  tokens  is  a  "marked”,  directed 
graph. 

Bv  assigning  a  set  of  tokens  to  a  subset  of  the  locations 
in  an  E-net  graph,  and  then  executing  the  transition  actions 
as  the  transitions  are  enabled  (in  accordance  with  the  rules 
and  definitions  which  follow),  the  token  flow  through  the 
E-net  can  represent  the  dynamic  activity  of  the  modeled  system. 
When  an  enabled  transition  fires,  it  removes  tokens  from  a  sub¬ 
set  of  its  input  locations  and  places  tokens  on  a  subset  of 
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its  output  locations  (Ref  15: lb).  The  transition  firing  time 
specification  and  the  modification  of  the  status  of  the  attach¬ 
ed  locations  provide  an  interpretation  of  the  transition 
function  (Ref  15:74),  completing  the  characterization  of 
E-nets  as  marked,  "interpreted",  directed  graphs. 

Basic  Definition.  This  section  presents  the  axioms  and 
definitions  that  underlie  the  basic  definition  of  an  E-net. 

For  a  thorough  discussion  of  the  theory  and  development  of 
E-nets,  the  reader  is  referred  to  chapter  2  of  Reference  15. 

Axiom  1  (Ref  15:30):  The  maximum  number  of  locations 
connected  to  a  transition  is  four.  The  limitation  facilitates 
precise  definition  of  the  concept  of  transition  action 
(Ref  15:30):  the  number  four  is  linked  to  the  number  of  primi¬ 
tive  transition  types  (5)  provided  in  E-nets.  A  location  may 
be  an  output  location  for,  at  most,  one  transition  and/or  an 
input  location  for,  at  most,  one  transition.  A  direct  result 
of  this  restriction  is  that  two  or  more  transitions  will  not 
compete  for  a  token  on  a  common  input  location  (race  condition). 

Definition  1  (Ref  15:30):  "A  location  is  empty  if  it 
does  not  contain  a  token  and  full  if  it  contains  a  token.  If 
it  is  not  known  whether  the  location  is  empty  or  full,  the 
status  of  the  location  is  undefined." 

Axiom  2  (Ref  15:30):  "A  location  may  change  from  empty 
to  full  or  full  to  empty  only  by  the  action  of  one  of  the 
transitions  to  which  it  is  connected." 

Aaciom  3  (Ref  15:31):  "The  action  of  a  transition  is 
defined  by  the  mapping  whose  domain  and  range  are  the  status 
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of  locations  connected  to  the  transition."  For  representa¬ 
tion  purposes,  the  status  of  locations  attached  to  a  transi¬ 
tion  are  represented  by  an  n-tuple,  where  n  is  the  number  of 
locations  attached  to  the  transition.  The  values  that  a  coor¬ 
dinate  in  the  n-tuple  may  take  are:  a)  1  if  the  status  is 
full,  b)  0  if  the  status  is  empty,  and  c)  ♦  if  the  status 
is  undefined. 

Definition  2  (Ref  15:32):  "A  peripheral  location  is  a 
location  having  exactly  one  connection  to  one  transition. 
Locations  oriented  into  (out  of)  a  transition  are  input 
( output )  locations  of  the  transition.  All  locations  that  are 
not  peripheral  locations  are  inner  locations." 

Definition  3  (Ref  15:32):  A  resolution  location 
<  (r-location)  is  a  location  that  is  directed  into  an  X  or  Y 

transition  (see  Definition  4).  Based  on  the  r-location  status 
of  0  or  1,  an  alternate  output  location  of  an  X  transition  or 
an  alternate  input  location  of  a  Y  transition  is  selected  for 
the  action  of  the  transition.  A  peripheral  r-location  may 
take  on  the  values  0,1,  or  <t> .  An  inner  r-location  may  only 
take  on  the  values  0  or  1  (Ref  15:32). 

Axiom  4  (Ref  15:33):  "Only  resolution  locations  may 
have  an  undefined  status." 

Definition  4  (Ref  15:35):  The  following  five  basic 
transition  types  are  provided  in  E-nets.  Letting  b^  and  b2 
represent  input  locations,  b^  and  b^  represent  output  loca¬ 
tions,  and  r  represent  a  resolution  location,  the  basic  tran- 
f  sition  types  with  their  corresponding  mappings  are: 
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T(b1,b3): 


(1,0)  -  (0,1) 


J(b1,b2,b3):  (1,1,0)  -  (0,0,1) 

F(b1,b2,b3):  (1,0,0)  -  (0,1,1) 

X(r,b1,b3,b4):  (0,1, 0,0)  -  (e, 0,1,0) 

(0,1, 0,1)  -  (e, 0,1,1) 

(1,1, 0,0)  -  (e, 0,0,1) 

(1,1, 1,0)  -  (e, 0,1,1) 

Y(r,b1}b2,b3):  (0,1, 1,0)  -  (e, 0,1,1) 

(0,1, 0,0)  -  (e, 0,0,1) 

(0,0, 1,0)  -  (e, 0,0,1) 

(1,1, 1,0)  -  (e, 1,0,1) 

(1,1, 0,0)  -  (e, 0,0,1) 

(1,0, 1,0)  -  (e, 0,0,1) 

"If  r  is  a  peripheral  location,  replace  the  character,  e 
by  otherwise  replace  e  by  0"  (Ref  15:35).  An  X  or  Y 
transition  action  leaves  the  status  of  peripheral  r-locations 
undefined  (how  their  status  becomes  redefined  is  discussed 
later).  Figure  12  illustrates  the  graph  representations  of 
the  corresponding  above  transition  types.  The  vertical  bars 
in  the  graphs  represent  the  transitions,  the  hexagons  repre¬ 
sent  resolution  locations,  and  the  circles  represent  standard 
locations.  The  mappings  of  the  left-hand  tuples  into  the 
right-hand  tuples  in  Definition  4  correspond  to  the  "firings" 
of  the  given  transitions.  A  more  formal  definition  of  a  tran 
sition  firing  is  available. 

( 
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Fig.  12  Basic  Transition  Types 


(Ref  15:35) 


Definition  5  (Ref  15:36):  "A  transition  firing  is  a 
three  phase  operation  consisting  of  the  following  phases : 

1)  Enable  phase  -  at  the  instant  the  status  of  the  loca¬ 
tions  connected  to  the  transition  satisfy  the  left- 
hand  side  of  the  transition's  definition,  the  tran¬ 
sition  is  enabled  and  begins  operation. 

2)  Active  phase  -  The  transition  action  is  in  progress, 
but  the  status  of  all  locations  attached  to  it  remain 
unchanged . 

3)  Terminate  phase  -  The  transition  action  is  completed, 
instantaneously  changing  the  status  of  all  associated 
locations  to  agree  with  the  right-hand  side  of  the 
transition  schema." 

Definition  6  (Ref  15:37):  A  transition  with  a  peripher¬ 
al  resolution  location  is  pseudo  enabled  whenever  the  status 
of  the  associated  locations  agrees  with  the  left-hand  side  of 
the  transition  schema  except  for  the  resolution  location  whose 
status  is  undefined  ($).  A  pseudo  enabled  transition  can  only 
become  enabled  when  the  net  environment  causes  the  status  of 
the  resolution  location  to  become  full  or  empty. 

Definition  7  (Ref  15:38):  The  transition  time  (firing 
time  or  processing  time)  of  a  transition,  a,  is  denoted  t(a), 
and  is  the  time  required  for  the  active  phase  of  a  firing  of 
transition  a.  T(a)  may  be  a  constant  value  for  all  tokens 
that  enable  a.  For  an  X  or  Y  transition,  t(a)  may  depend  on 
which  alternate  path  is  taken  (denoted  tg  (a)  if  the  "0"  path 

is  taken  and  t^(a)  if  the  "1"  path  is  taken)  (Ref  15:39). 

The  enabled  and  termination  phases  of  a  transition  firing  re¬ 
quire  zero  time.  These  two  phases  merely  represent  the  instan¬ 
taneous  setting  of  values  in  the  domain  and  range  of  a  transi¬ 
tion  mapping,  respectively. 


42 


Definition  8  (Ref  15:40):  An  Evaluation  net  structure 


E,  is  denoted  by 

E  =  (L,P,R,A)  where 

L  =  a  finite,  non-empty  set  of  locations, 

P  =  a  set  of  peripheral  locations,  P  £  L  , 

R  =  a  set  of  resolution  locations,  RS  L  ,  and 
A  =  a  finite,  non-empty  set  of  transitions,  {a^>,  where 

a.^  =  (s,t(a^));  s  e  S  and  tCa^)  t  T: 

S  =  a  finite,  non-empty  set  of  transition  types 
satisfying  Definition  4, 

T  =  {t(a^)  !  *  (a^)  is  a  transition  time  for  a.^  > 

Figure  13  shows  an  E-net  structure  whose  formal  descrip 
tion  is  as  follows  (Ref  15:40-41): 

E  =  (L,P,R,A) 

R  =  {r1,r2,r3,r^} 

P  =  {b1,b13}  U  R 

L  =  {b2,b3,b4,b5,b6,b7,bg,b9,b10,b11,b12}  U  P 

A  =  y  3.  )  3^  )^/|  )  ) 

at  =  (X  (r1,b1,b^,b3) ,(tQ(a1) ,t1(a1))  ) 

a2  —  (j(b2,b3,b3) ,t(a2) ) 

a3  =  ( Y(r2 , b^ , b^ , bg ) , ( tp( a3 ) , t^ ( a3 ) ) ) 

aA  =  ^ ^6  *^7  ’ ^8 ^  ^ ^ a4^ 
a^  —  ( F ( bg , bg , by ) , t ( a j ) ) 
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;-Net  Graph  of  Simple  System  (Ref  15:28) 


ag  -  (X(r2Sbg,b^^,b^Q),(tQ(ag),t^(ag))) 
a7  =  ( f( b^Q s b2 j b^2 ) » t ( 3y ) ) 

where  the  t(a^)  are  arbitrary  transition  time  expressions. 

Figure  13  is  a  simple  E-net  model  of  a  computer  system 
executive  where  a  job  which  enters  the  mix  may  need  a  tape 
drive.  A  job  that  needs  a  tape  drive  must  be  allocated  one 
(transition  a2  fires)  before  it  can  proceed  to  request  the  cen¬ 
tral  processor  (location  bg).  If  the  processor  is  idle  (b^ 
contains  a  token)  and  a  job  requests  it  (bg  contains  a  token) 

then  the  processor  is  allocated  (transition  a^  fires).  After 

a  job  has  finished  with  the  processor,  the  processor  is  deall¬ 
ocated  and,  if  applicable,  then  the  tape  drives  are  released. 

It  should  be  noted  that  the  resolution  locations,  r^j^jr^, 

and  r^,  serve  to  avoid  possible  conflicts  in  the  net. 
r-locations  r^  and  r^  determine  which  output  location  will 

receive  a  token  when  their  respective  transitions  fire, 
r-locations  ^  and  r^  determine  which  input  location  is  to  be 

considered  the  enabling  location  (and  will  lose  a  token)  when 
the  respective  transitions  fire.  Since  there  are  no  inputs  to 
and  r^  from  the  net,  it  is  assumed  that  the  environ¬ 
ment  of  the  net  will  set  the  values  of  the  r-locations 
(Ref  15:42).  It  should  also  be  noted  that  if  the  transition 
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times,  t(a^),  were  given,  it  would  be  possible  to  determine 
"a  time  for  tokens  to  traverse  the  net,  yielding  the  notion 
of  turnaround  time,"  (Ref  15:29). 

Net  Flow.  "  The  status  of  an  Evaluation  net  is  given  by 
providing  the  status  of  each  location  associated  with  the  net, 
where  each  location  is  empty,  full,  or  undefined"  (Ref  15:49). 
The  initial  marking  of  a  net  necessarily  precedes  the  begin¬ 
ning  of  operation  of  the  net.  Then,  either  a  transition  must 
fire  or  a  peripheral  location  must  become  empty  or  full  to 
change  the  net  marking  (Ref  15:50).  Additional  definitions 
are  provided  in  the  following  paragraphs  on  which  the  discus¬ 
sion  of  net  flow  is  formally  based. 

Definition  9  (Ref  15:50):  "Given  an  evaluation  net 
structure,  E  =  (L,P,R,A)  ,  a  marking  of  E  is  a  function,  M, 

taking  L  into  the  set  {0,1,*}."  A  marking  of  a  net,  E  is 
denoted  by 


M(bt)  =  j  ,  j  e  (0,1,*} 

for  all  b^  e  L.  M(b^ )  =  1  implies  that  location  ^  is  full, 
M(b^)  =  0  implies  that  b^  is  empty,  and  M(b^)  =  *  implies 
that  the  status  of  b^  is  undefined.  The  initial  status  of  L 

is  defined  by  the  initial  marking  of  E  ,  denoted  Mq. 

An  evaluation  net  can  now  be  defined  by  the  ordered  pair 
(E,M0)  (Ref  15:50).  Given  a  net  defined  by  (E,Mq),  let  a  re¬ 
sulting  sequence  of  transition  terminations  be  a.  ,  a.  . 

1  12 

Denoting  the  status  of  L  (the  set  of  net  locations)  after 
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transition  has  fired  by  M.  ,  the  sequence  Mq,M^,...,  M.  is 

1  j  J  J 

the  state  sequence  of  the  net,  E,  after  j  transitions  have 

terminated  (Ref  15:50).  Referring  to  Figure  13,  let 
MqCV  -  M0(b7)  =  1  , 

Mo(bi)  =  0  ,  i  =  2  , . . .  ,6 ,8 , . . .  ,13  and 

M0(rj)  =  0  ,  j  =  1,2, 3, 4  . 

Then,  the  state  sequence 

m0,m1,m3,m4,m5,m6,m8 

is  the  state  sequence  for  the  net  of  Figure  13  corresponding 
to  the  transition  termination  sequence 

al,a3,a4’a5,a6,a8 
and  with  initial  marking  Mq 

Definition  10  (Ref  15:51):  Given  the  net  E  =  (L,P,R,A)  , 
with  a^,a2j«»*,an  e  A  and  b^,b2»...,bn  e  L  where  b^  is 

directed  into  and  b^  +  ^  is  directed  out  of  a^^ ,  a  "path  in  E  of 

a  token  K  is  a  sequence  of  locations  that  K  resides  on  for  or¬ 
dered  firings  of  a^ ,a2 , • • • ,an  and  is  denoted  by 

=  b1}b2»...,bn  ,"  (Ref  15:51).* 

Definition  11  (Ref  15:51):  Given  (E,Mq),  the  dwell  time 

of  b^  e  L,  denoted  d(b^),  is  the  total  amount  of  time  that  the 
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status  of  has  been  full  since  the  net  was  initialized  with 

Mq.  The  dwell  time  of  token  K  on  b^ ,  denoted  d^(b^),  is  the 

total  amount  of  time  K  resided  on  location  b^ . 

It  is  intuitively  obvious  that  the  path  of  a  token  in  a 
net  may  indicate  the  utilization  of  facilities  represented  by 
the  locations.  Referring  again  to  Figure  13,  locations  b^  and 

b^-j  represent  the  input  and  output  control  points,  respective¬ 
ly,  of  a  computer  system  executive.  The  time  it  takes  a  token 
to  traverse  the  path  b^,...,b^j  in  Figure  13  corresponds  to 

the  "turnaround  time"  of  the  system  for  a  given  "task".  Like¬ 
wise,  the  ratio  of  the  dwell  time  d(bg)  to  the  total  net  oper¬ 
ation  time  corresponds  to  "central  processor  utilization".  To 
compute  the  dwell  time  of  a  particular  token  K  on  bg,  we  use 

the  formula 

dK(bg)  “  tj  -  tt 

The  value  t^  is  the  system  clock  time  at  which  the  termination 

phase  of  a  firing  of  a^  placed  token  K  on  location  bg.  Time 

tj  is  the  value  of  the  system  clock  when  the  termination  phase 
of  a  subsequent  firing  of  a^  moves  token  K  from  bg  to  bg .  The 

token  placed  on  location  by  when  transition  a^  fires  denotes 

that  the  processor  is  idle.  To  compute  d(bg),  we  use  the  formula 

d(bg)  =  dR  (bg)  +  dR  (bg)  +  •••  +  dR  (bg) 

12  n 
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where  the  n  tokens  K^,^,...,^  reside  on  location  bg  during 

the  net  operation  (i.e.  n  "jobs"  are  processed  by  the  system). 
Definition  12  (Ref  15:56):  "Given  (E,Mq)  and  a  path, 

yK  =  ^i>^2,*’‘,^n  *  ^he  traverse  time  of  a  token  K  through 

path  r,  denoted  D(yk),  is  the  time  that  K  leaves  location  bn 

minus  the  time  K  entered  location  b^." 

The  traverse  time  of  a  job  that  does  not  require  a  tape, 
in  Figure  13,  is  the  time  a  job  (token)  leaves  b^  minus  the 

time  it  entered  b^ .  Still  referring  to  Figure  13,  it  is  noted 

that  the  minimum  traverse  time  for  the  net  (the  time  for  a 
token  to  reach  b^g  after  it  has  been  placed  on  b^)  is  the  sum 

of  the  transition  times  t(a^) ,t(ag) ,t(a^) ,t(a^) ,t(a&) ,  and 
t(ag)  for  a  job  which  does  not  request  a  tape  drive.  The  act¬ 
ual  traverse  time  for  a  token,  K,  representing  a  "non- tape" 
job  is  the  sum  of  the  dwell  times  d^(b^)  +  d^(b^)  +  dR(bg) 

+  dK(b8)  +  dK(b9)  +  d.j^(b1  ^ )  .  For  any  token,  K,  represent¬ 

ing  a  non-tape  job  in  Figure  12,  the  following  relationship  is 
always  true  (Ref  15:56): 

1  t(a^)  £  z  dR(bj)  where  i  =  1,3, 4, 5, 6, 8 

and  j  =  1,4,6,8,9,11 

Formal  Evaluation  Net  Definition.  In  the  preceding  sec¬ 
tions,  the  basic  structure  of  an  E-net  has  been  introduced  and 
the  concept  of  net  operation  has  been  discussed.  In  this 


section,  the  token  structure  v$ i i  be  further  defined,  which 
leads  to  a  more  complete  description  of  locations.  Two  mech¬ 
anisms,  transition  procedures  and  resolution  procedures,  are 
introduced,  which  refine  the  concept  of  net  operation.  Also, 
a  special  token  called  an  environment  variable  is  introduced 
which  is  used  to  represent  a  portion  of  the  environment.  At¬ 
tribute  tokens,  transition  procedures,  resolution  procedures, 
and  environment  variables  complete  the  formulation  of  E-nets. 

A  formal  E-net  definition  is  presented ,  with  an  example,  at  the 
end  of  this  section. 

Definition  13  (Ref  15:61):  "A  simple  token  is  a  primi¬ 
tive  marker  which  indicates  that  a  location  is  full  whenever 
it  resides  on  that  location.  An  attribute  token  is  a  unique 
simple  token  that  has  a  finite,  non-zero  number  of  attributes 
associated  with  it." 

Attribute  tokens  require  a  different  notation  than  simple 
tokens  to  indicate  a  net  marking.  For  simple  tokens  on  a  lo^ 
cation,  b,  the  marking  of  b  is  denoted  M(b)  =1  or  M(b)  =  0 
for  b  full  or  empty,  respectively  (see  Definition  9).  If  the 
token,  K,  on  b  is  an  attribute  token,  then  additional  notation 
is  required  to  indicate  the  marking  of  b.  If  K  has  n  attri¬ 
butes,  then  the  token  is  denoted  K[n]  (Ref  15:61).  "The  ith 
attribute  of  K[n]  is  denoted  by  K(i),  for  1  <  i  <  n 
(Ref  15:62).  (Note  that  K[n]  refers  to  a  token  name  and  K(n) 
refers  to  a  token  attribute  value.)  Now  the  marking  of  loca^ 
tion  b  with  token  K[n]  residing  on  it  is  denoted  by 
M(b)  =  K[n]  ,  and  M(b)  =0  if  b  is  empty. 
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"Attribute  tokens  impose  a  data  structure  on  the  loca¬ 
tions  of  an  evaluation  net"  (Ref  15:62).  A  particular  loca¬ 
tion  will  always  receive  (provide)  a  token  with  a  fixed  num¬ 
ber  of  attributes.  It  is  not  required,  however,  that  all  of 
the  locations  attached  to  a  particular  transition  have  the 
same  number  of  attributes.  The  location  specifications  in  a 
net  description  must  be  redefined  to  incorporate  the  concept 
of  location  data  structure. 

Definition  14  (Ref  15:63):  Given  E  =  (L,P,R,A)  ,  and 

b^  e  L,  then  if  b^  may  contain  only  simple  tokens,  b^  is  de¬ 
clared  as  "b^".  Otherwise,  if  b^  may  contain  attribute  tokens 
with  fixed  n  attributes,  b^  is  declared  as  "b^[n]". 

The  it*1  attribute  of  a  token  K[n]  residing  on  b[n]  is  re¬ 
ferred  to  as  M(b(i)).  Suppose  that  a  transition,  a^ ,  places 

token  K[n]  on  location  b[m]  and  n  ^  m  .  If  g  is  the  smaller 
of  m  and  n,  then  the  marking  of  b[m]  after  a^  fires  is 

(Ref  15:63): 

M(b(l))  :=  K(l) 

M(b(2 ) )  :=  K(2) 

•  • 

•  • 

•  • 

M(b(g) )  :=  K(g) 

If  n  >  m,  then  the  attributes  m  +  1,...,  n  of  K[n]  are  lost. 

If  n  <  m,  then  the  values  M(b(n  +  1)),...,  M(b(m))  are  unde¬ 
fined  (Ref  15:64). 
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Suppose  now  that  transition  a^  is  a  J-type  transition 

(refer  to  Definition  4)  with  input  locations  b^[n]  and  ^[n] 

and  output  location  b^tn].  Suppose  also  that  b^[n]  and  b2[n] 

contain  two  distinct  tokens  K^[n]  and  ^[n].  After  the  tran¬ 
sition  fires,  locations  b^[n]  and  b2[n]  become  empty  and  a 

token  is  placed  on  location  b^[n] .  What  is  the  identity  of 

the  token  on  b^[n]?  This  is  one  example  (Ref  15:64)  of  why 

the  introduction  of  attribute  tokens  and  the  imposition  of 
data  structure  on  locations  requires  an  expanded  definition  of 
a  transition  declaration  in  order  that  the  function  of  a  tran¬ 
sition  may  be  fully  interpreted.  A  procedure  is  added  to  the 
transition  declaration  to  interpret  the  action  of  the  transi¬ 
tion  with  respect  to  the  attribute  tokens  place  on  the  tran¬ 
sition  output  location(s). 

Definition  15  (Ref  15:65):  "A  transition  procedure 
describes  the  action  of  the  environment  and  the  associated 
locations  of  the  transition  on  the  token.  The  form  will  be 
given  in  BNF"  (Ref  15:65-66)  (See  Appendix  A  for  an 
explanation  of  the  BNF  form  used  here): 

transition  procedure>  ::=  [  Conditional  list>] 
•Conditional  list>  ::=  <predicate>  -*■  (expression  list>: 

conditional  list>  | 

<predicate>  +  (expression  list> 
<Predicate>  ::=  <Boolean  factor>  | 

<predicate>  <Boolean  factor> 
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■^Boolean  factor2" 


::=  <Boolean  secondary>  | 

<Boolean  factor>  <Boolean  secondary> 
<Boolean  secondary>  ::=  <Boolean  primary>  | 

~  <Boolean  primary> 

<Boolean  primary>  ::=  T  |  F  <relation> 

<relation>  ::=  <right  partxrelational  operators 

cright  part> 

<relational  operator>  ::=>(>  |*|<|< 
expression  list>  ::=  <expression> ; expression  list>  | 

<expression>) 

<expression>  ::=  <left  partxright  part> 

<right  part>  :  :=  <term>  |  <add  opxterm>  | 

<right  partxadd  opxright  part> 

<term>  ::=  <factor>  |  <termxmult  opxfactor> 

<factor>  ::=  <primary>  |  <factor>  +  <primary> 

<primary>  : :=  cunsigned  number>  | 

<variable>(<right  part>)  | 

<variable> 

<mult  op>  ::=  *  |  / 
odd  op> :  :=  +  |  - 

<left  part>  ::=  <simple  variable>  := 

<variable>  ::=  oimple  variable>  |  <number> 

<simple  variable>  ::=  M(<location  name>(<attribute  #>))  | 

<environment  variable> 

<location  name>  ::=  b  e  {b  |  b[n]  E  L  or  b  e  L, 

b  <identifier> ) 


53 


<attribute  #>  :  :=  i  e  {i  ]  i  is  an  integer,  1  <_  i  <  n) 
<environment  variable>  : <identif ier>( <attribute  #>) 
<number>  ::=  <unsigned  number>  |  +  <unsigned  number >  | 

-  <unsigned  number > 

<unsigned  number >  ::=  <decimal  number >  | 

<exponent  part>  | 

<decimal  number >< exponent  part> 
<decimal  number>  ::=  <unsigned  integer>  | 

<decimal  fraction>  | 

<unsigned  integerxdecimal  fraction> 
<exponent  part>  <integer> 

<decimal  fraction>  ::=  .  cunsigned  integer> 

<integer>  ::=  <unsigned  integer>  |  +  cunsigned  integer> 

-  cunsigned  integer> 

cunsigned  integer>  =  cdigit>  |  cunsigned  integer>cdigit> 
cidentifier>  ::=  cletter>  |  cidentif ier>cletter>  | 
cidentifier>cdigit> 
cletter>  ::=  A  |  B  |  C  |  ...  |  z 
cdigit>  ::=  0  |  1  |  2  |  ...  |  9 

A  transition  procedure  has  the  form 

[Pl  +  (eu;...;eln):...:pK  -  (eR1 ; . . .  je^)  ] 

where  the  p^,  (1  £  i  £  K)  ,  are  cpredicate> ' s  and  the  e^j 

are  <expression> ' s  (Ref  15:66).  The  p^  are  evaluated  in 
numerical  order  starting  with  p^.  When  the  first  is 
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evaluated  to  true  (T) ,  its  corresponding  expression  list, 
e^ , . . .  >e^n,  is  executed  and  then  transition  procedure  eval¬ 
uation  is  terminated.  If  none  of  the  p^  are  true,  then  none 

of  the  expression  lists  are  executed.  The  previous  notation 
describing  an  E-net  structure,  Definition  8,  must  be  amended 
to  incorporate  the  following  definition  of  the  entry  A  in  the 
tuple  (L,P,R,A). 

Definition  16  (Ref  15:67):  The  set  of  transitions,  A, 
is  denoted  by: 

A  =  { (s ,t(a) ,q)  |  s  e  S,t(a)  e  T,q  e  Q> 

S  =  A  finite,  non-empty  set  of  transition 
schema  satisfying  Definition  4. 

T  =  {t(a)  |  t(a)  is  a  transition  time  for 

transition  a  (as  specified  in  Definition  7)). 

Q  =  A  finite,  non-empty  set  of  transition 
procedures  satisfying  Definition  15. 


The  addition  of  transition  procedures  requires  that 
part  3)  of  Definition  5  must  now  be  replaced  by  the  following: 


3)  "Termination  Phase:  The  transition  completes  pro¬ 
cessing,  changing  the  status  of  the  associated  lo¬ 
cations  to  agree  with  the  right-hand  side  of  the 
transition  by  executing  the  given  transition  pro¬ 
cedure  "  (Ref  15:67) 
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A  portion  of  the  environment  of  a  net  may  be  represented 
bv  a  specialized  attribute  token  known  as  an  environment  vari¬ 
able.  More  precisely,  environment  variables  form  part  of  the 


interface  between  a  net  and  its  environment. 

Definition  17  (Ref  15:68):  "An  environment  variable  is 
an  attribute  token,  K[n],  where  n  >  0  ,  that  represents  the 

status  of  a  portion  of  the  environment."  The  set  of  net  envi¬ 
ronment  variables  is  denoted  by: 


C  —  [ n^ ] , K2 [ n2 ],..., [ n^ ] 


There  are  two  wavs  to  reference  an  environment  variable. 
(Refer  to  Definition  15)  An  environment  variable  may  appear 
as  a  <left  part>  of  a  transition  procedure  <expression> .  The 
result  of  this  tvpe  of  reference  is  the  alteration  of  some 
attribute  of  the  environment  variable  (Ref  15:68).  An  environ¬ 
ment  variable  mav  appear  in  a  <predicate>  or  <right  part>  of 
an  <expression> .  The  result  of  this  type  of  reference  uses 
the  value (s)  of  the  environment  variable's  attribute (s ) ,  but 
does  not  alter  them  (Ref  15:68). 

A  restriction  on  net  interpretation  must  be  introduced  to 
prevent  race  conditions  with  repect  to  environment  variables. 

No  two  transitions  may  terminate  simultaneously  or  change  from 
pseudo  enabled  to  enabled  simultaneously  if  a  common  environ¬ 
ment  variable  is  involved.  A  transition  may  not  change  from 
pseudo  enabled  to  enabled  at  the  same  instant  that  another 
transition  terminates  if  a  common  environment  variable  is  in¬ 
volved  (Ref  15:96). 


Another  portion  of  the  net-environment  interface  has  al¬ 
ready  been  introduced:  peripheral  resolution  locations 
(Definition  3).  Referring  to  Definition  4,  when  an  X  or  Y 
transition  fires  and  the  transition's  input  r-location  is  also 
a  peripheral  location,  the  firing  of  the  transition  leaves  the 
status  of  the  resolution  location  undefined.  Before  the  tran¬ 
sition  can  become  enabled  again  the  environment  has  to  define 
the  resolution  location's  status  (Definition  6).  The  mechan¬ 
ism  for  defining  the  status  of  peripheral  resolution  locations 
is  the  resolution  procedure. 

Definition  18  (Ref  15:69):  "A  resolution  procedure  is 
an  expression 

't'(r)  =  f  :  [ <predicate>  M(r)  :=  s  : 

<predicate>  M(r)  :=  1  -  sj 

where  s  e  {0,1}  and  r  is  the  label  of  the  peripheral 
resolution  location.  Denote  the  set  of  resolution  procedures  as 

t  =  {v(r)  I  t (r )  is  a  resolution  procedure  and  r  e  P  R} 

If  the  first  <predicate>  is  true,  then  M(r)  is  set  to  s.  Else, 
if  the  second  <predicate>  is  true,  then  M(r)  is  set  to  1  -  s . 
Otherwise,  the  setting  of  r  remains  undefined"  (Ref  15:69). 

A  resolution  procedure  is  only  evaluated  when  the  transi¬ 
tion  is  pseudo  enabled  (see  Definition  6).  If  the  resolution 
location  status  is  still  undefined  after  the  resolution  proce¬ 
dure  is  evaluated,  then  the  value  of  at  least  one  argument  of 
one  of  the  <predicate> ’ s  must  change  before  the  resolution 
procedure  is  evaluated  again  (Ref  15:69). 


All  of  the  E-net  constructs  and  mechanisms  have  been  intro¬ 
duced,  and  it  is  now  possible  to  formulate  a  final  net  defin¬ 
ition  which  provides  the  E-net  structure,  the  initial  marking, 
and  the  environment  interface.  Following  the  general  defini¬ 
tion,  the  formal  net  description  of  the  net  in  Figure  13  will 
be  presented. 

Definition  19  (Ref  15:70):  "An  evaluation  net  is  a 
tuple , 

(E,M0(£,'0)  such  that 

E  =  (L,P,R,A)  is  an  evaluation  net  structure 
satisfying  Definition  8. 

MQ  is  an  initial  marking  (Definition  9). 

5  is  a  set  of  environment  variables  (Definition  17). 

t  is  a  set  of  resolution  procedures  (Definition  18). 

Before  presenting  a  formal  net  description  of  the  net  in 
Figure  1^,  it  is  desireable  to  refine  the  net  itself  by  incor¬ 
porating  attribute  tokens  in  the  net  model  to  represent  the 
"  iobs"  in  the  "system".  A  job  token  will  have  three  attributes: 

1)  K(l)  :  Central  processor  utilization  time. 

2)  K(2)  :  Tape  I/O  time. 

3)  K(3)  :  1  if  the  tape  drive  is  required,  0  otherwise. 

Assuming  that  processor  utilization  and  tape  I/O  are  fully  over¬ 
lapped,  the  processor  is  allocated  to  a  job  for  max  (K(l),  K(2)) 
time  units.  Other  assumptions,  related  to  tape  drive  allocation, 
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are  that  it  takes  45  seconds  to  fetch  a  tape  as  represented  by 
t^(a^)  and  it  takes  15  seconds  to  mount  or  dismount  a  tape  as 

represented  by  t(a2)  and  t(a?),  respectively.  The  formal  net 

definition  of  the  refined  model  of  Figure  13  is  as  follows 
(Ref  15:71-73): 

E  =  (L,P ,R,A) , 

R  =  (r^ ,r2 ,r3 ,r^} 

P  =  {b1[3],b13[3]}UR 

L»  (b2 ,b3[ 3] ,b4[ 3] ,b5[ 3] sb6[ 3] ,b7,b8[  3] , 

/ 

b9[3]5b10[3],bu[3],b12[3]}U  P 
4  =  ^  n  ^  ,  a  2  j  3^  j  3^ 

al  =  (X(r^ ,b^[ 3] ,b4[3] ,b3[ 3] ) ,  (0,45  seconds), 

I(M(r1)  =  1)  *  (M(b3[3]):=  M(b1[3] )): 

T  -  (M(b4[3]):=  M(b1[3]))]) 

a2  =  ( J(b2  ,b3[  3  ]  ,b^[  3])  ,  15  seconds, 

[T  -  (M(b5[3]):=  M(b3[3]))]) 

a3  =  (Y(r2,b4[3],b5[3],b6[3])}  (0,0), 

[ (M(b4[3] )/  0  A  M(b5[ 3] )  =  0)  ♦ 

(M(b6[3]):=  M(b4[ 3] ) ) : 

(M(b4[  3] )  =  0  A  M(b5[  3]  )#t  0)- 

(M(b6[3]):=  M(b5[3])): 

M(r2)=  0  -  (M(bg[ 3] ) :=  M(b4[3])): 

T  -  (M(b6[3]:=  M(b5[3]))]) 
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a4  =  U(b6[3],b7,b8[3l),  0, 

[T  -  (M(bg[  3]):  =  M(b6[3]))]) 
a5  -  (F(b8[3],b9[3],b7)f  max(M(bg(l) ) ,  M(bg(2))), 
[T  -  (CPU(l) : =  CPU(l)  +  M(bg ( 1 ) ) ; 

TI0(1) :=  TIO(l)  +  M(bg(2) ) ; 

M(b?)  :  =1)] ) 

a6  =  ,b^^l3] jb^Q[3]),  (0,0), 

[M(r3)  =  0  *  (M(b11[3]):=  M(b^[3]>): 

T  -  (M(b10[3]):=  M(bg [ 3 ] ) ) ] ) 
a7  =  (F(b1Q[  3]  ,b2  ,b^2[  3]  )  ,  15  seconds, 

[T  -  (M(b2):=l; 

M(b12[3}):^  M(b10t3]))]> 

a8  "  ^Y^r4  j^h  [  3 1  Jbi2  [  3 1  »bi3 1  3 1  ),  (0,0), 

[ (M(b11[ 3] )  ^  0  A  M(b12[3])  =  0)  - 

(M(b13[3]):=  M(btl[3]))s 
(M(b11[3])  =  0  A  M(b12[3])  4  0)  - 

(M(b13[3]):=  M(b12[3])): 

M(r4)  =  0  -  (M(b13[3]):«  M(bu[3])): 

T  -  (M(b13[3]):=  M(b12[3]))]) 

M0(b2)  "  M0(b7)  =  ^  M0(bi[3])  =  °» 

(for  all  1  <  i  £  13, 
i  ^  2,  i  4  7). 
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K  =  {CPU[ 1 ] ,  TI0[1] > 

*  =  {’Kr1),  <f'(r2) ,  >K(r3)J  ^(r^)  > 

'f(r1)  =  r1:[M(b1(3))  =  0  -  M(r1):=  0: 

T  -  M(ri):=  1] 

Y(r2)  =  f 2 : [T  -  M(r2):=l] 

»(r3)  =  r3:[M(b9(3))  =  0  -  M(r3);-  0: 

T  -  M(r3):=  1] 

y(r^)  =  r^:[T  -  M(r^):  =  1] 

This  new  definition  of  the  net  in  Figure  13  provides  a 
full  interpretation  of  the  graph.  When  a  token  is  placed  on 
location  b^,  transition  a^  is  pseudo  enabled.  Resolution  pro¬ 
cedure  y(r^)  is  then  evaluated.  Based  on  the  value  of  attri¬ 
bute  three  of  the  token,  M(r^)  will  be  set  to  0  or  1.  Assign¬ 
ing  the  value  0  or  1  to  r^  enables  transition  a^ .  Transition 

a^  fires,  with  firing  time  equal  to  45  or  0  seconds,  moving 
the  token  on  b^  to  b^  or  b3,  respectively.  The  environment 

variables,  CPU[l]  and  TI0[1],  are  updated  each  time  transition 
a^  fires,  providing  the  system  performance  measures  of  total 

CPU  and  tape  drive  usage.  Attribute  tokens,  transition  pro¬ 
cedures,  and  resolution  procedures  greatly  enhance  the  per¬ 
formance  measurement  capabilities  of  E-nets  while  providing 
a  clear  and  definitive  method  of  executing  the  net. 

Macro  Structures.  It  is  sometimes  desireable  to  be  able 
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to  "compress"  a  redundant  sequence  of  transitions  and  locations 
or  to  replace  a  cluster  of  nodes  with  a  simple  structure  which 
is  a  clear  and  more  concise  representation.  Macro  E-nets  are 
structures  which  provide  just  such  a  capability  (Ref  16,17). 
Macro  structures  can  be  derived  to  meet  the  needs  of  the  net 
under  consideration.  However  a  "standard"  macro  structure,  a 
priority-in  queue,  will  be  presented  since  they  appear  in  some 
of  the  nets  in  Chapter  III.  Formal  derivations  of  several 
types  of  macro  structures  can  be  found  in  Reference  15  (113-126) 
and  17. 

Figure  14  is  a  priority-in  queue  of  length  four  composed 
of  evaluation  net  primitives.  Each  non-resolution  location 
may  accept  an  attribute  token  K^[l]  with  one  attribute  ,  which 

represents  the  token's  priority.  Location  q4  is  the  tail  of 
the  queue  and  q^  is  the  head  of  the  queue.  Assume  the  follow¬ 
ing  net  marking: 

M(qt)  =  Kt[l ]  ,  Kt(l)  =  3  ; 

M(q2)  =  K2[l]  ,  K2(l)  =  1  ; 

M(q3)  =  M(q4)  =  M(bt)  =  M(b2)  =  M(ux) 

=  M(dt)  =  M(d2)  =  M(d3)  =  0  ; 

M(r^)  =  M(s^)  =  ,  for  i  =  1,2,3 

Now  place  K3[l]  on  b^ ,  with  K3(l)  =2  .  It  is  required  to 

place  K3[l]  on  q2  and  move  K2(l]  back  to  q3.  The  following 

markings  and  transition  firings  will  perform  the  needed  actions 
(Ref  15:115-116): 
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Fig.  14  Priority-In  Queue  of  Length  Four 


Set  M(s3)  =  0  ;  Fire  y3,  (move  K^tl]  forward). 

Set  M(s2)  =  0  ;  Fire  (move  K^fl]  forward). 

Set  M(r^)  =  0  ;  Fire  x^,  (move  K^tl]  forward). 

Set  M(r2)  =  1  ;  Fire  (m°ve  K2[l]  backward). 

Set  M(s2)  =  1  ;  Fire  >^3  (move  K2 [ 1 ]  to  q3). 

Set  M(s1)  =  0  ;  Fire  y^ ,  (move  K^tl]  to  q2)* 

Now,  K^[l]  resides  on  q^ ,  Kg[l]  resides  on  q2 ,  and  ^[1]  re¬ 
sides  on  q3,  and  q^  is  empty.  Since  setting  the  resolution 

locations  to  the  appropriate  status  causes  the  associated 
transitions  to  fire  it  is  sufficient  to  only  list  the  resolu¬ 
tion  location  settings  that  will  remove  the  token  from  the 
head  of  the  queue  (placing  it  on  location  b2)  (Ref  15:117): 

Set  M(rt)  -  0  . 

Set  M(r2)  =  0 
Set  M(r3)  =  0  . 

Set  M(s^)  =  0 

Now,  Kjfl]  resides  on  q^,  k2[l]  resides  on  q2,  and  q3  and  q^ 
are  empty. 

The  formal  definition  of  a  priority-in  queue  must  still 
be  stated  in  terms  of  the  primitive  constructs  when  the  over¬ 
all  net  definition  is  declared.  However,  the  substitution  of 
the  structure  in  Figure  15  for  the  net  in  Figure  14  would 
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present  a  much  clearer  picture  of  a  net  incorporating  a 
priority-in  queue  of  length  four  and  tokens  with  one  attri¬ 
bute  . 

Summary .  E-nets  are  characterized  as  marked,  interpreted, 
directed  graphs.  An  E-net  is  composed  of  two  sets  of  nodes, 
transitions  and  locations,  which  are  interconnected  by  direc¬ 
ted  arcs.  Tokens  are  markers  which  can  reside  on  the  locations 
(a  particular  location  may  hold  at  most  one  token).  A  token 
may  have  a  finite  set  of  attributes  with  values  assigned  to 
the  attributes.  Net  operation  (or  execution)  is  reflected  in 
the  movement  of  tokens  among  the  location  nodes  in  the  net. 
Tokens  are  moved  by  the  "firings"  of  transition  nodes.  When 
the  status  of  the  locations  attached  to  a  transition  satisfy 
defined  conditions,  the  transition  is  enabled  and  subsequent¬ 
ly  fires,  removing  tokens  from  a  subset  of  its  input  locations 
and  placing  tokens  on  a  subset  of  its  output  locations.  A 
transition  is  specified  by  a  tuple,  (s,t(a),q),  where  s  is 
the  transition  type,  t(a)  is  the  transition  "firing"  time  dur¬ 
ation,  and  q  is  a  transition  procedure  which  interprets  the 
action  of  the  transition  on  the  tokens  involved  in  a  particular 
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firing.  A  resolution  location  is  a  special  location  which 
provides  a  conflict  avoidance  mechanism  for  a  transition  which 
selects  a  token  to  be  removed  from  (placed  on)  either  of  two 
input  (output)  locations  when  the  transition  fires.  The  net- 
environment  interface  is  specified  by  peripheral  non-resolution 
locations,  resolution  procedures,  and  environment  variables. 

A  peripheral  location  has  only  one  transition  connected  to  it 
by  one  arc.  Peripheral  non-resolution  locations  provide  an 
input  (output)  for  tokens  from  (to)  the  environment  to  (from) 
the  net.  A  resolution  procedure  is  a  mechanism  for  defining 
the  status  of  peripheral  resolution  location.  An  environment 
variable  is  a  special  attribute  token  which  represents  the 
status  of  a  portion  of  the  environment.  Environment  varia¬ 
bles  can  be  referenced  by  resolution  procedures  and  referenced 
and  changed  by  a  transition  procedure.  In  the  next  chapter, 
an  E-net  graph  model  of  the  DAIS  will  be  developed  and  a 
formal  description  of  the  graph  presented. 


Ill  Model  Construction 


Prefatory  Activities 

Prior  to  the  actual  construction  of  a  system  model, 
guidelines  should  be  established  which  will  serve  to  keep  the 
modeling  effort  "on  track".  These  guidelines  can  often  be 
separated  into  functionally  diverse  groups  which  may  be  devel¬ 
oped  by  distinct  activities.  Three  activities  preceded  the 
actual  construction  of  an  E-net  model  of  the  DAIS:  a)  deter¬ 
mination  of  which  DAIS  components  and/or  functions  to  model, 
b)  determination  of  the  lowest  level  of  detail  to  be  modeled, 
and  c)  establishment  of  a  set  of  model  requirements. 

There  is  some  overlap  and  interdependency  among  these  three 
activities;  the  level  of  detail  may  be  restricted  or  bounded 
by  which  system  functions  are  modeled,  and  some  model  require¬ 
ments  will  be  established  or  tailored  to  consider  what  system 
functions  are  modeled. 

What  to  Model .  In  the  introduction  of  this  report  it  was 
stated  that  a  model  is  desired  which  could  be  used  for  high 
level  analyses  of  proposed  distributed  processor  avionics 
computer  systems.  For  this  investigation,  a  two  processor 
configuration  of  the  DAIS,  master  processor  plus  one  remote 
processor  (Ref  1,24),  is  modeled.  The  distributed  archi¬ 
tecture,  system  control,  and  concurrent  processing  activity 
of  the  DAIS  are  of  primary  interest.  The  processors,  their 
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associated  BCIUs,  and  the  data  bus  should  be  modeled.  The 
Remote  Terminals  and  other  avionics  components  (communications 
devices,  weapons,  altimeters,  etc.)  are  only  input  and/or  out¬ 
put  devices  to  the  computer  system.  Therefore,  they  do  not 
need  to  be  physically  represented  in  the  model;  only  the 
transmission  (reception)  of  messages  to  (from)  these  other 
components  from  (by)  the  processors  needs  to  be  modeled. 

System  control  refers  to  one  of  the  major  functions  of 
the  DAIS  Executive.  Data  bus  control  is  another  major  func¬ 
tion  of  the  Executive.  Both  of  these  functions  need  to  be 
modeled  in  order  to  analyze  system  operations  by  using  the 
model.  Another  type  of  control  function  that  is  not  so 
obvious  is  the  control  of  a  processor's  activity.  Which  task 
is  selected  for  execution  on  a  processor  depends  on  the  task's 
position  in  a  prioritized  list  of  tasks  that  are  ready  for  ex¬ 
ecution.  Some  tasks  (Normal  Mode  Tasks)  can  have  their  execu¬ 
tion  suspended  if  a  higher  priority  task  becomes  ready  to  ex¬ 
ecute.  Other  tasks  (Privileged  Mode  Tasks  and  Executive 
actions)  run  to  completion  once  their  execution  is  begun. 
Overriding  the  task  execution  function  is  the  hardware  inter¬ 
rupt  capability  of  the  BCIU  to  its  associated  processor.  Also, 
the  activity  (i.e.  utilization)  of  the  processors  and  their 
BCIUs  should  be  reflected  in  the  model,  to  support  efforts  to 
analyze  the  impact  of  adding  or  deleting  processors  from  a 
distributed  processor  configuration.  Finally,  the  interaction 
of  a  processor  with  its  BCIU  and  the  differences  in  operation 
between  Master  and  Remote  BCIUs  should  be  revealed  in  the 
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model,  as  points  of  major  interest  in  a  system  analysis. 

In  summary,  then,  the  components,  functions,  and  activ¬ 
ities  of  the  DAIS  to  be  modeled  are: 

1)  Distributed  architecture  (processors,  BCIUs,  and  Data  Bus), 

2)  System  control, 

3)  Data  Bus  control, 

4)  Task  control, 

5)  BCIU  interrupts  to  processors, 

6)  Task  priority  scheme, 

7)  Processing  activity, 

8)  BCIU  and  Data  Bus  activity,  and 

9)  Processor  -  BCIU  interaction. 

Level  of  Detail.  The  level  of  detail  at  which  to  model 
a  system  depends,  of  course,  on  the  intended  use  of  the  model. 

The  inherent  capabilities  of  the  modeling  schema  used  may 
limit  the  degree  of  detail  which  can  be  represented  by  a  par¬ 
ticular  model  type.  For  this  investigation,  a  level  of  detail 
is  desired  which  illustrates  the  DAIS  components,  functions, 
and  activities  listed  in  the  previous  section.  This  level  of 
detail  is  determined  to  be  the  task  level.  Tasks  and  Execu¬ 
tive  actions  are  represented  by  tokens,  whose  flow  through 
the  E-net  graph  will  simulate  the  flow  of  tasks  in  the  DAIS. 

Model  Requirements.  A  set  of  model  requirements  is  es¬ 
tablished  which  express  the  desired  capabilities  of  the  E-net 
model  representation  of  the  DAIS.  These  requirements  are, 
admittedly,  somewhat  subjective,  but  they  represent  the  intent 


of  this  investigation.  The  model  requirements  are: 


1)  The  E-net  graph  is  a  pictoral  representation  of  the 
DAIS  structure. 

2)  The  functions  and  activities  listed  in  the  section 
"What  to  Model",  above,  are  incorporated  into  the 
graph  structure  or  are  revealed  by  the  graph 
interpretation. 

3)  The  E-net  model  represents  the  DAIS  at  a  "task  flow" 
level  of  detail. 

4)  Interpretation  of  the  E-net  graph  simulates  the 
operation  of  the  DAIS  with  respect  to  task  flow  and 
the  system  control  and  bus  control  functions. 

5)  Analysis  of  the  interpretation  of  the  E-net  graph 
can  be  used  to  provide  answers  to  questions  about 
DAIS  performance  (especially  with  respect  to  processor 
utilization  and  bus  activity). 


Model  Development 

The  guidelines  provided  by  the  prefatory  activities  pro¬ 
vided  a  basis  on  which  to  begin  the  model  construction.  The 
approach  used  for  model  construction  was  top-down  development. 
The  first  graph  constructed  represents  the  DAIS  at  the  highest 
level.  Succeeding  graphs  representing  successively  greater 
levels  of  detail  were  constructed  until  a  level  of  detail  was 
reached  which  represented  the  flow  of  tasks  in  the  DAIS. 

Three  graphs  were  constructed  in  all;  they  are  presented  in 
the  following  sections  in  the  order  of  their  development. 

For  the  first  two  graphs,  only  the  basic  E-net  description  is 
given,  since  these  graphs  were  not  to  be  interpreted.  The 
first  and  second  graphs  constructed  do  not  meet  requirements 
2)  and  3)  under  "Model  Requirements",  above,  but  they  do  repre¬ 
sent  the  DAIS  at  high  levels  of  detail  and  they  give  insight 
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into  the  step-by-step  method  of  developing  the  E-net  graph 
model  which  is  the  end  product  of  this  investigation. 


Top  Level  Model .  The  first  stage  in  the  top-down  model 
development  was  the  construction  of  a  very  high  level  graph 
representation  of  the  DAIS.  This  "top  level"  model  is  seen 
in  Figure  16.  The  nodes  in  the  graph  are  defined  as  follows: 

a^  :  add  job  to  master  processor  queue 

a2  •*  allocate  the  master  processor  to  a  job 

a^  :  deallocate  the  master  processor 

a^  :  dispose  of  last  job  executed  on  master  processor 
a^  :  place  message  on  bus 

a^  :  transfer  message  from  bus  to  a  processor 
a -j  :  add  job  to  remote  processor  queue 
ag  :  allocate  the  remote  processor  to  a  job 
ag  :  deallocate  the  remote  processor 

a^:  dispose  of  last  job  executed  on  remote  processor 

b^  :  a  job  is  ready  to  execute 
b2  :  master  processor  is  allocated 
bg  :  master  processor  is  deallocated 
b^  :  job  execution  is  completed 

b^  :  master  processor  message  awaits  transmission 
bg  :  last  job  did  not  generae  a  bus  message 
by  :  remote  processor  message  awaits  transmission 
bg  :  the  bus  is  busy 

bg  :  a  message  for  the  master  processor  has  been  received 
b^gi  a  message  for  the  remote  processor  has  been  received 
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1-Net  Graph  of  the  DAIS 


b^:  a  job  is  ready  to  execute 

b^2:  remote  processor  is  allocated 

b^:  remote  processor  is  deallocated 

b^:  job  execution  is  completed 

b^:  last  job  did  not  generate  a  bus  message 

:  priority-in  queue  for  master  processor 

Qn  :  priority-in  queue  for  remote  processor 
r^  :  choose  jobs  for  input  to  master  processor  queue 
:  detect  bus  messages 

r^  :  collect  messages  for  bus  transmission 
r^  :  choose  processor  to  receive  message 
r,.  :  choose  jobs  for  input  to  remote  processor  queue 
r^  :  detect  bus  messages. 

In  this  top  level  model,  the  environment  places  jobs  on 
locations  b^  and  b^  for  the  master  processor  and  remote  pro¬ 
cessor,  respectively,  Q^Jj]  and  (^[j]  represent  priority-in 
queues  of  executable  jobs.  Jobs  work  their  way  to  the  head 
of  their  queues  and  eventually  are  executed.  Some  jobs  may 
generate  a  bus  message.  Jobs  which  do  not  generate  bus 
messages  exit  the  graph  at  nodes  b^  and  b^.  If  a  bus  message 

is  generated,  a  token  is  placed  on  location  bg  or  by,  appro¬ 
priately.  For  example,  if  a  job  represented  by  token  K  is 
placed  on  location  b^,  and  this  job  needs  to  send  the  results 

of  its  computation  to  the  remote  processor,  the  path  followed 
by  K  is 

bl»  Qm»  b2»  b4 ’  b6 ’  b8>  b10»  b12»  On’  b12’  b14’  b15  # 
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The  formal  definition  of  the  graph  in  Figure  16  is  as 


follows : 

E  =  (L,P  ,R,A) 

R  =  {r1,r2,r3,r^,r5,r6} 

P  =  {b1,b5,b11,b15}  (J  R 

L  =  {b2,b3,b4,b5,b6',b7Jb8Jb9  ,  biO’b12’b13,Qm,Qn}  \J  P 

A  =  {&1  ,a2,a3,a4,a5  ,afi  ,  a7  ,ag  ,ag  ,a1()} 

a^  =  (  Y  ( r^ ,  bg  ,  b^ ,  )  ,  (tQ(a^)}  t^(a^))) 

a2  =  *  t^a2^ 
a3  =  (F(b2 ,b3,b4)  ,  t (a3) ) 
a4  =  (X(r2,b4,b5Jb6)  ,  (tQ(a4)  ,  t1(a4))) 

citj  =  ( Y(r 3  , 1 ^ ,  1 7 , tg )  ,  (tQCa^)  ,  t^(a^)  )  ) 
a6  =  (^(r4  s^g  ,  tgCag)  ,  t^(ag))) 

a7  -  (Y(r5  >0^  >  ^to(a7)  ’ 

a8  =  (dCC^ , b^ 3 , b^ 2 )  j  t(ag) ) 
ag  =  (f(b^2 jb^3 }b^4)  ,  t(ag) ) 

a10  =  (X(r6’b14,b7’b15^  »  (t0(a10)  » 


The  graph  in  Figure  16  provides  a  very  high  level  of 
observation  of  the  DAIS  structure.  The  distributed  architec¬ 
ture  and  parallel  processing  capability  are  visible.  Some 
operational  features  and  system  functions  and  components  are 
not  visible  at  this  level  of  detail,  such  as  BCIU  operation, 
BCIU  Interrupt  capability  to  its  processor,  and  the  processor- 
'o-BCIU  programmed  I/O  interface.  Jobs  are  considered  to 


execute  to  completion  once  they  are  begun. 


Intermediate  Level  Model .  The  next  step  in  the  modeling 
process  was  the  construction  of  an  E-net  graph  of  the  DAIS 
which  represents  the  operation  and  structure  of  the  DAIS  at 
a  finer  level  of  detail  than  that  provided  by  the  top  level 
model.  This  next  step  model,  or  intermediate  level  graph, 
is  seen  in  Figure  17.  The  nodes  in  this  graph  are  defined 
and  the  formal  definition  of  the  net  is  presented  in 
Appendix  B. 

The  distributed  architecture  and  parallel  processing 
capability  are  revealed  in  the  intermediate  level  model  of 
the  DAIS.  BCIU  operation  and  portions  of  the  processor-BCIU 
interface  are  also  visible  at  this  level  of  observation. 

The  bottom  half  of  the  figure  on  sheets  1  and  2  of  Figure  17 
represent  the  master  and  remote  BCIUs ,  respectively.  Sheet 
3  of  Figure  17  is  the  portion  of  the  E-net  graph  which  repre¬ 
sents  the  data  bus  and  its  interconnections  to  the  BCIUs  and 
RT  (at  this  level,  nodes  b^-j  and  b^Q  represent  the  bus  con¬ 
nections  of  all  RTs  and  directly  connected  bus  compatible 
avionics  subsystems). 

The  master  processor  executes  jobs  (which  can  represent 
tasks  at  this  level  of  detail)  it  receives  at  location  b^  and 

processes  asynchronous  requests  it  receives  at  location  b^. 

A  processing  activity  runs  to  completion  unless  a  higher 
priority  activity  becomes  ready  to  execute  (and  works  its  way 
to  the  head  of  the  processor  queue),  in  which  case  the 
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Fig.  17  (2  Of  3)  Intermediate  Level  E-Net  Graph  of  the  DAIS 


currently  executing  job  is  suspended.  The  suspended  job  is 
fed  back  into  the  queue  (bg  to  b2  to  C^)  and  the  processor 

is  allocated  to  the  highest  priority  job  in  the  queue.  If 
a  job  generates  a  bus  message,  then  a  token  is  placed  on 
location  by  after  the  job  is  executed  (at  this  level  of  ob¬ 
servation  a  job  may  only  generate  a  message  if  it  completes 
execution,  since  the  firing  of  transition  a^  can  only  place 

a  token  on  bg  or  by).  Placing  tokens  on  by  and  b,^  represents 

PIO  operations  by  the  master  and  remote  processors,  respect¬ 
ively. 

Locations  b^  and  b^  and  locations  b^Q  and  b^2  represent 

portions  of  the  master  and  remote  BCIUs ,  respectively.  Locations 
b^  and  b^2  receive  messages  from  the  data  bus  for  their  respect¬ 
ive  BCIUs.  The  BCU  portion  of  the  BCIU  processes  messages 
from  the  bus  and  its  associated  processor.  The  BCU  activity 
is  represented  by  transitions  ag  and  a<j  for  the  master  BCIU 

and ' transitions  a^g  and  a2Q  for  the  remote  BCIU.  Messages  to 
be  transmitted  onto  the  bus  are  placed  on  locations  b^  and 

b30* 

Although  the  level  of  observation  provided  by  the  E-net 
in  Figure  17  reveals  more  operational  and  functional  charac¬ 
teristics  than  the  top  level  graph  does,  some  functions  and 
control  aspects  are  still  not  visible.  Specifically,  the  task 
control i  bus  control,  and  system  control  functions,  the  BCIU 
interrupt  capability  to  the  processor,  and  the  task  priority 


scheme  are  not  visible. 

Task  Level  Model.  A  task  flow  level  of  detail  is  repre¬ 
sented  by  the  E-net  graph  in  Figure  18.  The  formal  definition 
of  this  net  and  the  definitions  of  the  nodes  in  the  net  are 
presented  in  Appendix  C. 

The  task  level  E-net  graph  in  Figure  18  is  a  pictoral 
representation  of  the  DAIS.  Sheets  1  and  2  of  Figure  18 
represent  the  master  processer,  sheets  4  and  5  represent  the 
remote  processor,  and  sheet  6  represents  the  remote  BCIU.  The 
upper  half  of  sheet  3  represents  the  master  BCIU  and  the  lower 
half  represents  the  data  bus. 

One  of  the  assumptions  made  during  development  of  the 
task  level  model  (and  the  previous  two  models)  is  that  there 
is  no  major  difference  in  how  tasks  are  executed  in  the 
master  and  remote  processors.  Any  differences  are  in  the 
functions  of  the  tasks  being  executed  in  each  processor. 
Another  assumption  is  that  the  Master  Interrupt  Handler  is 
functionally  identical  to  the  Local  Interrupt  Handler,  at  the 
task  flow  level  of  detail,  with  respect  to  how  interrupts  from 
the  BCIU  are  processed.  Unavailability  of  detailed  documenta¬ 
tion  on  the  Master  Executive  is  the  motive  for  these  assump¬ 
tions.  The  effect  of  these  assumptions  is  that  the  portions 
of  the  task  level  E-net  graph  representing  the  master  and  re¬ 
mote  processors  are  identical. 

System  control  is  provided  by  a  collection  of  functions 
(see  page  20).  Error  management,  configuration  management, 
and  mass  memory  management  were  not  incorporated  into  the 


80 


Fig.  18(1  of  6)  Task  Level  E-Net  Graph  of  the  DAIS 


Fig.  18  (2  Of  6)  Task  level  E-Net  Graph  of  the  DAIS 


Master  BCIU 


Task  Level  E-Net  Graph  of  the  DAIS 


Remote  Processor 


Task  Level  E-Net  Graph  of  the  DAIS 


DAIS  configuration  modeled  (Ref  24:28-32).  Therefore,  these 
functions  are  not  incorporated  into  the  task  level  E-net 
graph.  Control  and  task  flow  required  for  system  synchron¬ 
ization  are  incorporated  into  the  model.  The  master  processor 
sends  commands  to  the  remote  processor  via  the  subnet  inter¬ 
connections  labeled  D,E,H,  and  I  in  that  order. 

Data  bus  control  is  represented  by  the  interconnections  of 
the  data  bus  and  BCIUs  and  by  the  flow  of  tokens  representing 
tasks  and  signals.  The  PIO  connection  between  the  master 
(remote)  processor  and  the  master  (remote)  BCIU  is  represented 
by  location  b^g  (bgg).  The  master  BCIU  places  commands  on 
the  bus  at  location  b^  and  receives  responses  at  location  b^g. 


The  remote  BCIU  processes  commands  it  receives  from  the  bus 
at  location  b5y  and  places  responses  to  commands  on  the  bus  at 
location  b^,..  Locations  b^2  and  b^^  represent  the  connection 


of  the  RTs  and  other  bus-compatible  avionics  subsystems  to  the 
data  bus . 

A  BCIU  sends  an  interrupt  to  its  processor  whenever  it 
receives  a  bus  message  which  requires  executive  action.  The 
master  processor  receives  an  interrupt  whenever  the  master 
BCIU  receives  a  "request  for  services"  from  the  remote  proces¬ 
sor.  The  local  processor  receives  an  interrupt  whenever  its 
BCIU  receives  an  asynchronous  transmit  or  receive  command. 
These  interrupts  are  received  by  the  master  and  remote  proces¬ 
sors  at  locations  bgQ  and  b-^g,  respectively.  An  interrupt  is 


processed  in  the  model  by  executing  an  interrupt  task  which  is 
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created  at  locations  and  for  the  master  and  remote 
processors,  respectively. 

Task  control  and  the  task  priority  scheme  are  interrelated. 

A  task  is  represented  by  an  attribute  token,  K[8]: 

1)  K(l)  :  1  if  an  interrupt  task,  0  otherwise 

2)  K(2)  :  1  if  a  Normal  Mode  task,  0  otherwise 

3)  K(3)  :  task  priority  (1  is  highest) 

4)  K(4)  :  processor  time  required,  in  milliseconds 

5)  K(5)  :  processor  time  used,  in  milliseconds 

6)  K(6)  :  1  for  synchronous  bus  command 

2  for  asynchronous  bus  command 

7)  K(7)  :  integer  value  representing  a  request  for  services 

8)  K(8)  :  BCIU  processing  time. 

The  position  of  a  task  (token)  in  a  processor  priority-in 
queue,  (^[8]  or  Qpl8],  is  determined  by  the  value  of  the  task's 

(token's)  second  attribute.  All  interrupt  tasks  have  priority 
1,  all  Priviledged  Mode  and  executive  tasks  have  priority  2, 
and  Normal  Mode  tasks  have  priority  3  thru  n,  where  n-2  is  the 
number  of  Normal  Mode  tasks  in  the  processor. 

Task  control  is  concerned  with  the  order  of  execution  of 
tasks,  the  allocation  and  deallocation  of  a  processor  to  a  task, 
and  the  thread  of  control  from  a  task  back  through  the  calling 
sequence  to  the  Master  Sequencer  (Figure  9)  or  the  executive. 

The  order  of  execution  of  tasks  is  controlled  with  the  processor 
queues,  (^[8]  and  Qp[8].  The  allocation  of  the  processors  is 
controlled  at  r-locations  r^  and  r ^ g.  When  the  master  (remote) 


88 


l 


r 


processor  becomes  idle  (location  b^y  (by^)  *-s  empty),  the  task 
at  the  head  of  Q^Qp)  is  removed  from  the  queue  and  receives 

control  of  the  processor.  The  allocation  of  the  master  (remote) 
processor  is  represented  by  the  successive  firings  of  transi¬ 
tions  a^  and  a^  (a^  anc*  a53^  after  r  (r^  )  is  set  to  0. 

Deallocation  'of  the  processors  is  more  complicated. 

Deallocation  of  a  processor  depends  on  the  class  and  prior¬ 
ity  of  the  task  currently  in  control  of  the  processor  (see 
page  33).  Once  a  Privileged  Mode  or  executive  task  starts 
executing  it  runs  to  completion.  However,  execution  of  a 
Normal  Mode  task  is  suspended  whenever  a  higher  priority 
task  becomes  executable.  In  the  model,  the  master  (remote) 
processor  is  deallocated  by  the  successive  firings  of  transi¬ 
tions  a yj  and  a^g  (a^g  and  a^g).  The  marking  of  r-location 

r6  (r27)  is  undefined  until  one  of  two  things  happens.  If  an 

interrupt  is  received  by  the  master  (remote)  processor  during 
execution  of  a  Normal  Mode  task,  then  a  token  is  placed  on 
location  bg  (bgg),  which  will  cause  the  marking  of  r^  (*27) 

to  be  changed  to  1,  enabling  transition  a^y  (a^g).  If  a 

Privileged  Mode  or  executive  task  is  executing,  or  if  an 
executing  Normal  Mode  task  is  not  suspended,  then  the  normal 
termination  of  the  executing  task  will  define  the  value  of 
M(rg)(of  M(r2y))  to  be  0.  Transition  a^y  (a^g)  then  fires,  ' 

since  a  token  is  always  available  on  location  b22  (bgg). 
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Processor  activity  is  represented  by  a  token  on  locations 
b and  b^g  for  the  master  and  remote  processors,  respectively. 
Tokens  on  these  locations  represent  the  execution  of  applica¬ 
tions  tasks,  executive  services,  and  interrupt  processing. 

The  other  transitions  and  locations  in  the  processor  portions 
of  the  E-net  model  system  overhead  activities  such  as  al¬ 
location  of  the  processor,  clearing  of  interrupts,  entering 
tasks  in  the  queues,  and  PIO.  BCIU  activity  is  represented 
by  the  allocation  of  the  BCM  in  the  master  and  remote  BCIUs 
(locations  b^g  and  b^.^,  respectively),  the  transmission  and 
reception  of  messages  (locations  b^^ ,  b^ ,  b^g,  and  b^g), 

and  the  generation  of  interrupts  (locations  b^Q  and  b^g). 

Interpretation  of  the  E-net  graph  in  Figure  18  simulates 
DAIS  operation.  It  is  assumed  that  the  net  environment, 
places  attribute  tokens  (tasks)  on  locations  b^  and  bgg  to 

simulate  the  activation  of  executable  tasks  in  the  DAIS.  It 
is  also  assumed  that  the  environment  changes  the  value  of 
the  environment  variable  CLOCK  to  represent  the  passage  of 
real  time.  Given  an  initial  marking  Mq  for  the  graph,  the 

model  is  executed  by  firing  transitions  as  they  are  enabled 
and  in  accordance  with  the  formal  definition  in  Appendix  C.  An 
example  is  presented  in  the  next  section. 

Interpretation  of  the  model  results  in  the  automatic 
collection  of  some  data.  Locations  bg,  bg,  b^g,  bgg,  bgg, 

b&i»  bgy ,  byg,  bg^,  and  bg^  are  used  to  collect  data  on 


t 


90 


interrupts  and  tasks  (see  Appendix  C  for  location  definitions). 
Other  performance  data  can  be  calculated  by  measuring  dwell 
times  at  locations  b^,  b^g,  b^,  b11Q,  C^,  C^,  and  Qp.  In 

the  next  section,  an  example  of  how  a  token  (task)  flows 
through  the  graph  (DAIS)  is  presented. 

Model  Validation.  Validation  of  any  model  is  generally 
achieved  by  convincing  oneself  that  the  model  actually 
represents  the  structure  and/or  the  function  of  the  modeled 
system.  For  a  simulation  model,  validation  is  accomplished 
by  "exercising"  the  model  with  a  "representative"  (and,  of 
course,  validated)  workload  model.  If  the  performance  of  the 
model  approximates  the  actual  system  performance  under  the 
workload  that  was  modeled,  then  the  model  is  validated.  How 
accurate  the  approximation  must  be  for  a  particular  validation 
effort  is  subjective. 

For  this  investigation,  validation  of  the  high  and  inter¬ 
mediate  level  models  was  accomplished  by  exercising  these 
models  in  a  manner  similar  to  the  example  at  the  bottom  of 
page  71.  It  was  only  necessary  to  validate  the  structure  of 
these  two  models  since,  for  this  investigation,  they  were 
only  to  be  used  as  stepping  stones  to  the  task  level  model. 

The  task  level  model  was  initially  validated  in  the  same 
manner  as  the  first  two  models.  The  structure  of  the  task 
level  model  was  validated  in  subsections,  and  then  pieced 
together  for  an  overall  validation  effort.  Validation  of 
the  function  of  the  model  was  accomplished  by  introducing 
tokens  to  the  net  at  locations  b^  and  b^^  and  then  interpreting 
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the  model.  An  example  of  this  effort  is  in  Appendix  D. 

The  bookkeeping  involved  during  the  graph  interpretation 
becomes  quite  tedious  and  prone  to  error  as  the  interpretation 
progresses.  A  more  convincing  validation  process  might  involve 
an  automated  interpretation  of  the  model  with  a  workload  model 
derived  from  an  actual  workload,  but  the  amount  of  effort 
required  is  beyond  the  resource  limitations  of  this  investi¬ 
gation. 

Summary 

A  set  of  guidelines  was  established  as  a  basis  tor  the 
model  construction  effort.  A  top  down  approach  was  used 
during  model  development.  Three  models  were  constructed;  the 
third  one  represents  the  DAIS  at  a  task  flow  level  of  detail. 
All  three  models  were  validated  with  respect  to  their  struc¬ 
ture.  The  task  level  model  was  interpreted  to  provide  a  rough 
validation  of  its  function  and  performance.  An  evaluation  of 
the  three  models  constructed  is  provided  in  the  next  chapter. 
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IV  Evaluation  Of  Models 


E-nets  were  developed  as  a  system  analysis  tool  (Ref  15:23). 
Analysis  of  the  net  interpretation  provides  performance 
measures  of  the  system  represented  by  the  net.  Since  E-nets 
are  also  pictoral  representations  of  the  systems  they  model, 
it  should  also  be  possible  to  perform  some  system  analysis 
based  on  the  uninterpreted  graph  representation  of  the  modeled 
system.  An  evaluation  of  the  models  constructed  during  this 
investigation  as  analysis  tools  is  presented  in  this  chapter. 

Some  possible  methods  of  analyzing  the  graphs  are  also 
discussed . 

Structural  Analysis 

All  three  models  constructed  could  be  used  to  analyze  the 
DAIS  architecture.  The  interconnection  of  system  components 
is  represented  by  the  interconnection  of  nodes  in  the  net. 

The  three  models  can  be  viewed  as  block  diagrams  of  the  DAIS, 
at  successively  greater  levels  of  detail.  With  the  nodes  de¬ 
fined  and  labeled,  the  control  and  data  paths  between  system 
components  are  apparent.  Referring  to  Figure  18,  location  b^g 

represents  a  register  in  the  master  BCIU  which  receives  PIO 
instructions  from  the  master  processor.  The  master  BCIU  is 
interfaced  to  the  data  bus  via  the  MTU  which  is  represented 
by  location  b^. 

Part  of  the  interface  between  the  system  and  its  environ¬ 
ment  is  represented  by  the  peripheral  locations  in  the  net 
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graphs.  In  Figure  18,  locations  and  represent  the 

connection  of  bus-compatible  avionics  subsystems  to  the  avion¬ 
ics  computer  system  (DAIS). 

A  high  level  representation  of  some  DAIS  system  functions 
is  also  revealed  in  the  graph  structures.  Also,  the  break¬ 
down  of  some  functions  into  subfunctions  is  revealed.  In 
Figure  19,  the  overall  system  function  is  composed  of  the 
processor/BCIU  and  data  bus  functions.  The  master  processor/ 
BCIU  function  is  composed  of  the  processor  allocation,  pro¬ 
cessor  deallocation,  and  BCIU  function.  (Figure  19  could  also 
represent  the  physical  composition  of  the  system.) 

With  the  nodes  defined,  the  graphs  represent  the  events 
or  activities  occurring  in  the  system  and  the  conditions  which 
must  be  satisfied  for  the  events  to  take  place.  It  is 
apparent,  using  the  definitions  in  Appendix  C  for  nodes  r^, 

a17’  ^8*  ^22 5  anc*  ^23 5  from  the  graph  in  Figure  18  that  the 
master  processor  will  be  deallocated  whenever  the  currently 
executing  task  terminates  normally,  or  if  an  interrupt  occurs 
during  execution  of  a  Normal  Mode  task. 

The  graph  structures  can  be  used  to  analyze  the  DAIS 
structure  and  part  of  the  interface  between  the  DAIS  and  its 
environment.  It  is  possible,  given  the  node  definitions,  to 
analyze  the  ordering  of  sequences  of  events.  In  order  to 
analyze  the  performance  of  the  DAIS,  however,  it  is  necessary 
to  interpret  the  nets. 
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Dynamic  Analysis 

Examples  of  how  to  interpret  E-nets  are  provided  in 
Chapters  two  and  three.  The  performance  measures  which  could 
be  made  by  interpreting  each  of  the  three  models  are  discussed 
in  Chapter  three.  Other  performance-related  issues  could  be 
studied  by  interpreting  the  nets. 

If,  during  the  interpretation  of  the  task  level  net  a 
marking  was  reached  in  which  no  transition  was  enabled  (or 
would  be  enabled  within  a  finite  time  period  for  the  task  level 
net),  then  the  net  would  be  dead.  A  dead  net  represents  a 
hung-up  or  deadlocked  system.  If  all  interpretations  of  the 
task  level  net,  initialized  with  the  same  Mq,  CLOCK  value,  and 
task  input  times,  resulted  in  the  same  terminal  marking  at  time 
tT,  then  the  net  (and  the  DAIS)  is  deterministic. 

Interpretation  of  all  three  models  developed  is  possible. 
However,  sets  of  transition  procedures  and  resolution  proce¬ 
dures,  and  the  location  data  structures  of  the  high  and  inter¬ 
mediate  level  nets  will  have  to  be  provided  before  these  two 
nets  could  be  interpreted.  Interpretation  of  each  net  would 
provide  performance  measures  at  corresponding  levels  of  detail. 
Several  possible  ways  to  interpret  the  nets  are  discussed  in 
the  next  section. 

Direct  Interpretation.  One  method  of  interpreting  the 
nets  in  Chapter  three  would  be  to  assign  an  initial  marking, 
initialize  a  subset  of  the  net's  environment  variables,  and 
then  record  the  changes  in  the  net  marking  as  transitions 
become  enabled  and  fire.  An  example  of  this  method  is  in 
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Appendix  D.  Additionally,  a  data  table  could  be  constructed, 
where  each  entry  in  the  table  represents  a  marking  of  the  net. 
Such  a  table  (or  similar  method  of  recording  data)  would  be 
necessary  to  monitor  the  net  operation  when  several  tokens 
are  moving  about  in  the  net  concurrently.  For  even  a  rela¬ 
tively  simple  net  like  the  high  level  net,  the  recording 
effort  can  be  substantial,  and  for  a  large,  complex  model, 
the  recording  effort  can  be  prohibitive. 

Data  recording  associated  with  an  interpretation  of  the 
high  level  model  could  be  done  manually,  although  much  time 
would  be  required  to  simulate  DAIS  operation  of  even  a  few 
minutes.  An  intermediate  level  net  interpretation  requires 
a  substantially  greater  recording  effort.  If  attribute  tokens 
are  used  for  an  intermediate  level  net  interpretation,  then  a 
vector  of  n  values  (where  n  is  the  number  of  token  attributes) 
is  associated  with  each  token.  A  single  row  entry  requires 
41  columns,  one  for  each  location,  in  a  table  representing 
the  net  markings.  Additionally,  a  table  of  token  values  must 
be  maintained  where  each  row  entry  corresponds  to  an  attribute 
token  in  the  net  and  each  column  entry  corresponds  to  an 
attribute  of  the  token.  It  is  easily  derived  from  the  example 
in  Appendix  D  and  the  discussion  above  that  to  manually 
record  the  data  generated  by  a  task  level  net  interpretation 
is  out  of  the  question.  An  alternative  method  of  collecting 
and  recording  the  data  associated  with  a  task  level  net  inter¬ 
pretation  is  required. 


A  net  interpretation  could  be  automated.  A  net  inter¬ 
pretation  computer  program  could  be  constructed  as  a  main 
program  with  calls  to  subprograms.  The  main  program  would 
contain  the  logic  necessary  to  sequence  the  subprogram  calls. 
Subprograms  would  implement  transition  procedures.  A  sub¬ 
program  call  would  only  be  valid  if  the  transition  was 
enabled.  Data  recording  could  be  done  in  the  main  program, 
a  common  subprogram,  or  in  each  subprogram.  Ideally,  an 
automated  interpretation  of  the  models  in  Chapter  three 
would  be  executed  in  real  time  on  a  multiple  processor  com¬ 
puter  system  with  concurrent  processing  capabilities. 

However,  not  many  systems  like  this  are  available.  Also,  the 
programming  effort  required  for  a  direct  interpretation  pro¬ 
gram  could  be  prohibitive  or  not  cost-effective. 

Simulation.  An  alternative  to  direct  interpretation 
with  a  computer  program  is  simulation  of  the  net  interpreta¬ 
tion  with  a  computer  program.  Several  simulation  programs 
exist  which  could  conceivably  be  used  (GASP-IV,  GPSS,  Q-GERT, 
and  SLAM  are  a  few  examples).  A  brief  discussion  of  how  the 
GASP-IV  program  could  be  used  to  simulate  interpretation  of 
the  task  level  net  follows. 

The  main  functions  performed  by  GASP-IV  are  data  collec¬ 
tion  and  supervisory  control  of  the  simulation.  Additional 
functions  include  statistical  analyses  of  the  data  collected, 
generation  of  inputs  to  the  model,  and  report  generation.  A 
GASP-IV  model  of  a  net  in  Chapter  three  could  consist  of  a 
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set  of  queues  and  servers,  representing  locations  and  transi¬ 
tions,  respectively. 

GASP-IV  supports  event-and  time-driven  simulations.  If 
enabling  a  transition  is  represented  by  an  event,  then  an 
event-driven  simulation  of  a  net  interpretation  would  be 
possible.  GASP-IV  provides  and  maintains  up  to  ten  files  for 
recording  events.  Input  to  an  event  file  would  correspond  to 
enabling  a  transition.  Output  from  the  same  event  file  would 
correspond  to  termination  of  a  transition  firing.  Event  file 
entries  can  have  several  components,  one  of  which  is  used  to 
place  the  entry  in  the  file.  The  file  above  could  be  ordered 
by  transition  firing  times. 

All  simulation  programs  have  implementation  bounds  on 
storage  for  data  collection  and  recording  and  on  the  size  of 
the  simulation  model.  These  restrictions  may  limit  the  use 
of  some  simulation  programs  for  net  interpretation. 

Summary 

E-nets  were  developed  as  a  performance  analysis  tool. 

It  is  possible  to  analyze  the  structure  and  functional  rela¬ 
tionships  of  the  DAIS  by  analyzing  the  nets  in  Chapter  three. 

A  performance  analysis  requires  an  interpretation  of  the  nets. 
Although  it  would  be  possible  to  manually  interpret  the  net 
models  of  the  DAIS,  the  data  collection  and  recording  effort 
would  be  substantial  even  for  the  high  level  net.  Possible 
alternatives  to  manual  interpretation  of  the  nets  are 
automated  direct  interpretation  and  simulation. 
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V  Results  And  Conclusions 


In  this  chapter,  the  results  of  this  investigation  are 
presented,  followed  by  some  concluding  remarks.  Then  some 
recommendations  for  future  work  are  offered. 

Results 

The  physical  end  product  of  this  investigation  is  a  set 
of  three  E-net  graph  models  of  the  DAIS,  a  distributed  pro¬ 
cessor  avionics  computer  system  architecture.  The  three 
models  represent  the  DAIS  at  successively  lower  levels  of  de¬ 
tail.  The  highest  level  net  models  the  major  components 
(e.g.  processor)  and  the  lowest  level  net  represents  the  DAIS 
at  the  task  flow  level  of  observation. 

It  is  demonstrated  that  a  particular  class  of  graph  models. 
E-nets,  can  be  used  to  model  a  distributed  computer  architect¬ 
ure.  Several  methods  for  analyzing  the  models  constructed  are 
presented,  including  analysis  of  the  static  graph  structures 
and  analysis  of  interpreted  nets  (dynamic  graphs). 

It  is  shown  how,  by  using  tokens  (markers)  in  the  net 
graph  to  represent  jobs  (tasks)  in  the  system  model,  to  simu¬ 
late  DAIS  operation.  Methods  for  collecting  performance  data 
during  a  simulation  (net  interpretation)  are  presented. 

An  evaluation  of  the  models  constructed  is  presented. 

The  evaluation  discusses  how  the  models  could  be  used  to 
analyze  the  structural,  functional,  and  operational 
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characteristics  of  the  DAIS.  The  problem  of  collecting  and 
recording  data  during  a  DAIS  simulation  is  discussed  and 
examples  are  provided. 

Conclusions 

The  top  down  approach  used  to  construct  the  E-net  graph 
models  of  this  investigation  was  quite  effective.  The  three 
models  produced  provide  three  separate  levels  of  observation 
of  the  DAIS.  The  inherent  modularity  of  E-nets  aided  the 
construction  effort,  reducing  the  difficulty  of  interconnecting 
subsections  of  a  net  graph  as  they  were  developed.  A  restric¬ 
tion  of  E-nets  is  that  the  termination  time  of  a  net  activity 
(event)  during  net  interpretation  is  fixed  when  the  activity 
is  initiated.  Consequently,  the  processor  interrupt  function 
of  the  DAIS  is  not  obvious  in  the  graph  and  required  the  only 
use  of  net  environment  variables  when  the  model  was  executed. 

The  parallel  processing  capability  is  incorporated  into 
the  net  interpretation  and  the  distributed  architecture  of 
the  DAIS  is  represented  in  the  graph  structure.  Although  the 
interpretation  of  E-nets  is  straightforward,  the  bookkeeping 
involved  during  interpretation  of  even  a  relatively  simple 
net  can  be  substantial  and  tedious.  Interpretation  of  any  of 
the  E-net  graphs  constructed  during  this  investigation  should 
be  facilitated  by  data  automation  techniques. 

Recommendations  for  Future  Work 

The  product  of  this  investigation  is  a  set  of  E-net 
graphs  which  represent  the  DAIS  computer  system.  The  models 


can  be  used  to  analyze  the  structure  of  and  the  functional 
relationships  in  the  DAIS.  However,  to  analyze  the  per¬ 
formance  and  operational  characteristics  of  the  DAIS,  the  net 
graphs  need  to  be  interpreted  (the  model  is  executed).  Work¬ 
load  models  need  to  be  developed  for  input  to  the  DAIS  models. 

In  addition  to  a  workload  model,  a  data  automated  capa¬ 
bility  needs  to  be  developed  to  perform  the  data  recording 
function  associated  with  a  net  interpretation.  Preferably, 
the  entire  interpretation,  including  the  bookkeeping  function, 
could  be  automated.  Two  alternatives  for  automating  the  inter¬ 
pretation  of  the  net  graphs  are:  a)  programs  could  be  written 
which  would  interpret  the  graphs  directly,  or  b)  an  existing 
simulation  program  could  be  used  to  simulate  the  net  inter¬ 
pretations  . 
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Appendix  A:  BNF  Notation 


The  Backus-Naur-Form  (BNF)  notation  used  to  describe  a 
transition  procedure  (Ref  15:65-66)  is  described  using  the 
following  example: 

<macro>  ::=  <micro>  |  <macroxopxmicro> 

<micro>  ::=  <basic>  |  <basic><micro> 

<basic>  : :=  a  |  b  |  c 
<op>  : : =  +  |  * 

The  constructs  <macro> ,<micro> ,<op> ,  and  <basic>  are  non¬ 
terminal  symbols.  The  symbols  a,b,c,+,  and  *  are  terminal  sy- 
bols.  The  symbols  |  and  ::=  are  meta  symbols.  The  symbol  ::= 
is  interpreted  to  mean  "replace  with".  Whatever  is  on  the  left 
side  of  ::=  may  be  replaced  by  whatever  is  on  the  right  side. 
The  symbol  |  indicates  a  choice  or  option.  That  is,  <op>  may 
be  replaced  by  +  or  *  .  Using  the  rules  for  replacement  ill¬ 
ustrated  in  the  above  example,  the  following  are  legal  con¬ 
structions  made  up  of  terminal  symbols: 

ab  +  ab 

aba  *  bcb  +  cac 

For  the  notation  used  in  the  transition  procedure  definition, 
::=  and  |  are  meta  symbols,  anything  enclosed  with  (and  inclu¬ 
ding  for  notation  purposes)  the  symbol  pair  <  >  is  a  non¬ 
terminal  symbol,  and  all  other  symbols  are  terminal  symbols. 


Appendix  B  Definition  of  the  Intermediate 
Level  E-Net  Graph  of  the  DAIS 


The  nodes  in  the  E-net  graph  of  Figure  17  are  defined  as 
follows : 

a^:  pass  activated  or  suspended  job  to  remote  processor 

queue 

a 2’  Add  job  or  asynchronous  request  to  master  processor 
queue 

a^:  allocate  the  master  processor 

a^:  deallocate  the  master  processor 

a^:  pass  bus  messages  to  master  BCIU  queue 

a^:  feed  suspended  jobs  back  to  master  processor  queue 

a7:  add  bus  messages  and  processor  commands  to  master 

BCIU  queue 

ag*.  allocate  BCM  of  master  BCIU 

a^:  deallocate  BCM  of  master  BCIU 

a10*  route  messages  for  transmission  to  data  bus 

a^:  route  asynchronous  requests  to  master  processor 

a^2:  pass  activated  job  or  suspended  job  to  remote 

processor  queue 

a^:  add  job  or  asynchronous  command  to  remote  processor 

queue 

a^:  allocate  the  remote  processor 

a^:  deallocate  the  remote  processor 

a16:  Pass  bus  messages  to  the  remote  BCIU  queue 

a feed  suspended  jobs  back  to  remote  processor  queue 

a1ft:  add  bus  messages  and  processor  commands  to  remote 
1  BCIU  queue 
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a^:  Allocate  BCM  of  remote  BCIU 

&2o'  deallocate  BCM  of  remote  BCIU 

b-2^’  route  messages  for  transmission  to  data  bus 

&22:  route  asynchronous  commands  to  remote  processor 

&2y  Pass  bus  messages  from  processors  to  bus 

&2k:  Pass  RT  transmissions  and  processor  messages  to 

"4  data  bus 

&25:  allocate  the  data  bus 

&26:  deallocate  the  data  bus 

&27:  route  messages  to  RT  or  processor/BCIU 

&28:  route  messages  to  master  or  remote  BCIU 

b^  :  a  job  is  ready  to  execute 

b2  :  an  executable  job  requests  the  master  processor 
bg  :  master  processor  is  allocated 
b^  :  master  processor  is  deallocated 
b^  :  job  execution  terminated 

bg  :  a  terminated  job  did  not  generate  a  bus  message 

by  :  bus  message  needs  to  be  transmitted 

bg  :  terminated  job  was  suspended 

bg  :  terminated  job  completed  execution 

b1Q:  BCM  of  master  BCIU  allocated 

b^ :  BCM  of  master  BCIU  deallocated 

b^2:  message  needs  to  be  routed 

b^g:  message  was  received  from  bus 

b^:  message  is  ready  for  transmission 

b^:  asynchronous  request  needs  to  be  processed 

b^:  received  message  requires  no  further  processing 
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a  job  is  ready  to  execute 

b^g:  an  executable  job  requests  the  remote  processor 

b^g:  remote  processor  is  allocated 

b2Q:  remote  processor  is  deallocated 
b2^:  job  execution  terminated 

b22:  terminated  job  did  not  generate  a  bus  message 

^2^'  bus  message  needs  to  be  transmitted 

b2^:  terminated  job  was  suspended 

b2^:  terminated  job  completed  execution 

^>2S:  of  remote  BCIU  allocated 

b2^:  BCM  of  remote  BCIU  is  deallocated 

b2g:  message  needs  to  be  routed 

b2^:  message  was  received  from  bus 

bgQ:  message  is  ready  for  transmission 

bg^:  asynchronous  command  needs  to  he  processed 

bg2:  received  message  requires  no  further  action 

bgg!  message  from  RT 

bg^:  message  from  a  processor 

bg^:  data  bus  requested 

bg^:  data  bus  busy 

bgy:  data  bus  idle 

bgg:  message  transmission  complete 

bggt  message  is  for  a  processor 

b^:  message  to  RT 

b^:  message  is  to  master  processor 

b^2:  message  is  to  remote  processor 
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master  processor  queue 

master  BCIU  queue 

remote  processor  queue 

remote  BCIU  queue 

choose  jobs  for  master  processor 

choose  jobs  and  requests  for  input  to  master 
processor  queue 

r^  :  detect  bus  messages 

r^  :  detect  job  complete  or  suspended 

r^  :  choose  bus  messages  for  master  BCIU  queue 

r^  :  detect  messages  to  be  transmitted 

r -j  :  determine  if  message  is  asynchronous  request 

rg  :  choose  jobs  for  remote  processor 

Tg  :  choose  jobs  and  requests  for  input  to  remote 
processor  queue 

r1Q:  detect  bus  messages 

r^:  detect  job  complete  or  suspended 

r^2:  choose  bus  messages  for  remote  BCIU  queue 

r detect  messages  to  be  transmitted 

r^:  determine  if  message  is  asynchronous  command 

r15:  ch°ose  processor  messages  to  be  placed  on  bus 

r^g’.  choose  processor  and  RT  messages  to  be  placed  on  bus 

r^y:  detect  messages  to  RT 

r^g:  determine  if  message  is  to  master  or  remote  processor 
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The  formal  definition  of  the  net  in  Figure  17  is: 

E  =  (L ,P ,R , A) 

R  -(t-l.r2.^.r4,-:5,r6,r7,r8,r9,r10>r11,rl2,r13,r14,r15> 

rl6’r17’r18} 

P  ={bl,b9»b16,bl7,b25,b32,b33,b40}  ^  R 


=  fb2  s  • 

• • >b8  >bio5  *  * ' ,bi5 

,bl8’  * . . ,b24s 

|b26 5  *  *  * 5 

b31 

b34’ 

• • • >^40*  U  P 

!  fa15a 

2 1  *  * • »a28} 

al  = 

(Y(r1 }blsbg3b2) 

1  ^  to^ al ^  } ( 

a±))) 

a2  = 

(Y(r2,b25b155Qm) 

5  ^  t0( a2  ^  * ^i 

(a2))) 

a3  = 

(j(Qm»b4>b3)  »  t(a3)) 

a4  = 

(F(b^,b^,b^)  ,  t(a^)) 

a5  = 

( X ( t ^  j j  3 )  i 

>  ^co^a5^  5  t 

1(a5))) 

a6  = 

(X(r4,b6)b8,bg)  , 

(t0(a6)j  tl 

(a6))) 

a7  = 

(Y(r5 »by  jb^^ ,0^) 

>  ^0(87)  »  1 

4(37))) 

a8  = 

^J(Qn,bll ,b10>  J 

t(ag)) 

a9  = 

(F(b10>bi2>bn)  5 

t(a9)) 

t 

o> 

o 

II 

(X<r6 ,b12 ,b13 ,b14 

)  ,  (tQ^lO^ 

»  tl(a10 

))) 

all  = 

(X(r7 ,b13Jb15,b16 

)  »  ( tQ ( a^ ) 

»  tl^all 

))) 

a12  = 

Wr8,b17,b24,b18 

)  j  ( £q( a^2 ) 

5  tl(a12 

))) 

al3  = 

(Y(r9  jbig ,b3^ ,Qp) 

»  ^0^13^  5 

( a^3 ) ) ) 
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a14  =  ( J^p,b20,b19’)  5  t^ai4^ 

a15  =  (^F(bi9>b2i>b20)  *  t^a15^ 

a16  =  ^X^r10,b2l’b22,b23'’  ’  ^0^16^  tl^al6^') 

a17  =  ^X^rll,b22,b24,b25^  s  ^c0^a17^  5  ci(ai7))) 

a18  =  (-Y^r12,b23,b42,^s')  5  ^c0^a18^  5  tl^a18^^ 

a19  =  (J(Qs>b27>b26)  5 

a20  =  ('F^b26’b28’b27^  *  t^a20^ 

a21  =  ('r13,b28,b29’b30^  5  ^CG^a2l^  5  Cl^a21^^ 

a22  =  (‘X('rl4,b29  ,b31  ,b32^  5  ^C0^a22^  »  tl^a22^^ 

a23  =  ^r15 ,bl4,b30,b34^  5  ^Cc/a23^  5  Cl^a23^ 

a24  =  ^Y^r16,b33’b34,b35^  5  ^c0^a24^  J  tl^a24'>^ 

a25  =  ^^b35 ,b37 ,b36 ^  5  b^a25^ 

a26  =  ^F^b36 ,b38 ,b37^  »  t^a26^ 

a 27  =  ^X^r17’b38,b39’b40^  »  ^0^27^  ’  cl/a27^ 

a28  =  ^X^r18,b39  ,b4l  ,b42  ^  ’  (to^a28^  »  tl^a28^^ 


The  definitions  of  the  nodes  in  the  E-net  graph  in  Figure 
are  as  follows: 


a^  :  route  master  processor  interrupts 
&2  :  collect  interrupt  flags 

a^  :  pass  interrupts  to  master  processor  queue 
a^  :  absorb  interrupt  flags 
a^  :  route  interrupt  flags 

a,  :  collect  interrupt  falgs  which  occur  during 
u  execution  of  non-Normal  Mode  tasks 

a -j  :  absorb  interupt  flags  which  occur  during 
execution  of  non-Normal  Mode  tasks 

ag  :  pass  activated  tasks  and  suspended  Normal  Mode  tasks 
to  the  master  processor  queue 

ag  :  pass  executable  tasks  to  master  processor  queue 

a^:  add  interrupts  and  tasks  to  master  processor  queue 

a^:  remove  task  from  head  of  master  processor  queue 

a^2:  allocate  the  master  processor 

a^g:  project  time  at  which  currently  executing  task  would 

end  if  it  runs  to  completion 

a^:  absorb  end-of-task  flags 

a^:  pass  end-of-task  flags 

create  end-of-task  flags 

a^yt  pass  end-of-task  flags  and  interrupts 

a^gt  deallocate  the  master  processor 


a-^gt  separate  Normal  Mode  tasks  from  other  tasks 

a2Q^  route  suspended  Normal  Mode  tasks  back  to  master 
processor  queue 

a2^:  separate  BCIU  related  tasks  from  other  non-Normal 

Mode  tasks 

a99:  separate  BCIU  related  tasks  from  other  Normal  Mode 

tasks 

a2^:  collect  non-BCIU  related  non-Normal  Mode  tasks 

a2^:  absorb  non-BCIU  related  non-Normal  Mode  tasks 

a2^:  collect  non-BCIU  related,  completed  Normal  Mode  tasks 

a2^:  absorb  non-BCIU  related,  completed  Normal  Mode  tasks 

a27:  collect  BCIU  related  tasks 

a2§:  route  BCIU  tasks  to  the  master  BCIU  queue 
a2gi  route  messages  from  bus  to  BCM  in  master  BCIU 
collect  tokens  signalling  end  of  BCM  activity 
a^:  pass  messages  from  bus  to  BCM  in  master  BCIU 

a^2:  collect  end-of-action  flags  for  BCM  in  master  BCIU 

a^:  un-busy  the  BCM  in  the  master  BCIU 
^ :  add  BCIU  operations  to  master  BCIU  queue 

a^:  allocate  the  BCM  in  the  master  BCIU 

a^:  process  the  BCIU  operation 

a-^:  route  outgoing  messages  to  bus,  incoming  asynchron- 

:  ous  requests  to  the  master  processor  * 

a^g:  collect  bus  messages  from  remote  BCIU  and  RT 

a^gi  messages  placed  on  the  bus 

a^:  route  messages  off  bus 

a^ :  route  messages  to  BCIUs 

a42:  route  remote  processor  interrupts 
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a :  collect  interrupt  flags 

a44:  Pass  interrupts  to  remote  processor 

a^:  absorb  interrupt  flags 

a^g:  route  interrupt  flags 

a collect  interrupt  flags  which  occur  during 
execution  of  non-Normal  Mode  tasks 

a/g:  absorb  interrupt  flags  which  occur  during 

execution  of  non-Normal  Mode  tasks 

a49:  pass  activated  tasks  and  suspended  Normal  Mode 

tasks  to  the  remote  processor  queue 

a50:  Pass  executable  tasks  to  remote  processor  queue 

a^:  add  interrupts  and  tasks  to  remote  processor  queue 

a^2:  remove  task  from  head  of  remote  processor  queue 

a^:  allocate  the  remote  processor 

aS4;  project  time  at  which  currently  executing  task 
would  end  if  it  runs  to  completion 

a^:  absorb  end-of-task  flags 

a^g:  pass  end-of-task  flags 

a 57 :  create  end-of-task  flags 

a<jgt  pass  end-of-task  flags  and  interrupts 

a^:  deallocate  the  remote  processor 

ag q.‘  separate  Normal  Mode  tasks  from  other  tasks 

ag^:  route  suspended  Normal  Mode  tasks  back  to  remote 
processor  queue 

afi9 :  separate  BCIU  related  tasks  from  other  non-Normal 
Mode  tasks 

as separate  BCIU  related  tasks  from  other  Normal  Mode 
63  tasks 

a separate  BCIU  related  tasks  from  other  Normal  Mode 
04  tasks 
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ag^:  absorb  non-BCIU  related  non-Normal  Mode  tasks 
aggt  collect  non-BCIU  related,  completed  Normal  Mode  tasks 
a gyi  absorb  non-BCIU  related,  completed  Normal  Mode  tasks 
agg:  collect  BCIU  related  tasks 

ag^:  route  BCIU  related  tasks  to  the  remote  BCIU  queue 

a-jQ-  pass  response  or  message  to  response 
a pass  remote  processor  request 

a-j2:  Pass  remote  processor  request  or  remote  BCIU  response 

update  remote  processor/BCIU  status 

a :  pass  updated  status  or  response  +  status 

a7c;:  pass  response  +  status  to  bus  and  clear  status  in 
remote  BCIU 

a^g:  pass  current  status 

a77:  collect  end  of  action  flags  for  the  BCM  in  the  remote 

'  BCIU 

a^g:  un-busy  the  BCM  in  the  remote  BCIU 

a yg:  pass  BCIU  tasks  to  BCM  when  BCM  not  busy 

agQ:  allocate  the  BCM  in  the  remote  BCIU 

ag^:  route  messages  to  bus 

ag2^  pass  asynchronous  commands  to  remote  processor 

b^  :  interrupt  received 

b2  :  an  interrupt  needs  to  be  processed 

bg  :  current  count  of  interrupts 

b^  :  updated  count  of  interrupts 

bg  :  interrupt  flag 

bg  :  task  to  process  an  interrupt 

by  :  interrupt  occurred  during  execution  of 
Priviledged  Mode  or  executive  task 
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b 

b 

b 

b 

b 

b 


16 

17 

18 

19 

20 
21 
22 


( 


23 

524 

*25 

>26 

J27 

528 

}29 


30 


interrupt  occurred  during  execution  of 
a  Normal  Mode  cask 

current  count  on  interrupts  when  executing  task 
not  a  Normal  Mode  task 

updated  count  of  interrupts  when  executing  task 
not  a  Normal  Mode  task 

activated  task  ready  to  execute 

activated  task  or  suspended  task  requests  master 
processor 

executable  task  requests  master  processor 

task  at  head  of  queue  bumped  by  entry  into  queue 
of  higher  priority  task 

highest  priority  task  in  queue  is  selected  for 
execution 

copy  of  task  in  master  processor 
master  processor  allocated 

current  count  of  allocation  of  the  master  processor 

updated  count  of  allocation  of  the  master  processor 

updated  count  of  completed  tasks  in  master  processor 

current  count  of  completed  tasks  in  master  processor 

enabling  token  used  when  executing  task  runs  to 
completion 

stop  execution  of  executing  task 

task  just  executed  by  master  processor 

completed  Priviledged  Mode  or  executive  task 

Normal  Mode  task  was  executing 

Normal  Mode  task  ran  to  completion 

Normal  Mode  task  was  suspended 

task  just  completed  was  not  BCIU  related 

task  just  completed  was  BCIU  related 
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bg^:  Normal  Mode  task  just  completed  generated  a  BCIU 
operation 

boot  Normal  Mode  task  just  completed  did  not  generate  a 
BCIU  operation 

bgg:  current  count  of  completed,  non-BCIU  related, 

Priviledged  Mode  and  executive  tasks  in  the  master 
processor 

bg>:  updated  count  of  completed,  non-BCIU  related, 

Priviledged  Mode  and  executive  tasks  in  the  master 
processor 

bgg:  updated  count  of  completed,  non-BCIU  related,  Normal 
Mode  tasks  in  the  master  processor 

b,gt  current  count  of  completed,  non-BCIU  related, 

30  Normal  Mode  tasks  in  the  master  processor 

bg^:  BCIU  operation  needs  to  be  processed 

bgg!  a  bus  message  needs  to  be  processed 

bgg:  interrupt  has  been  processed  by  the  master  processor 

and  BCM  in  master  BCIU  can  be  unbusied 

b^Q:  status  response  received  from  remote  device  does  not 

require  processing 

b^:  status  response  received  from  remote  device  requires 

further  processing 

b^2:  status  response  received  or  master  processor 

interrupt  has  been  handled  so  BCM  can  be  unbusied 

b^g:  response  to  last  command  is  received 

b^:  service  request  from  remote  device 

b^:  the  BCM  in  the  master  BCIU  can  be  unbusied 

b^g:  the  BCM  in  the  master  BCIU  is  not  busy 

b a  master  BCIU  operation  requires  processing 

b^g:  the  BCM  in  the  master  BCIU  is  busy 

b^:  a  master  BCIU  operation  is  executing 

b50:  a  remote  device  response  requires  processing  by 
the  master  processor 


* 
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b,-1  :  a  message  needs  to  be  transmitted  on  bus  by  the 
master  BCIU 

bc2:  an  RT  or  the  remote  processor  needs  to  be  transmitted 

on  the  bus 

b^j1  a  message  needs  to  be  transmitted  on  the  bus 

b,.^:  a  message  is  on  the  bus 

b^:  the  message  is  for  an  RT 

b^^:  the  message  is  for  a  processor 

b^:  the  message  is  for  the  remote  processor 

b^g:  the  message  is  for  the  master  processor 

b^g:  interrupt  received 

bgQ:  an  interrupt  needs  to  be  processed 

bg^:  current  count  of  interrupts 

bg2:  updated  count  of  interrupts 

bgg:  interrupt  flag 

bg^:  task  to  process  an  interrupt 

b6^:  non-transmit  interrupt  occurred  during  execution 
of  Priviledged  mode  or  executive  task 

b interrupt  occurred  during  execution  of  a  Normal 
Mode  task 

b current  count  of  interrupts  during  execution  of 
a  non-Normal  Mode  task 

bgg:  updated  count  of  interrupts  during  execution  of 
a  non-Normal  Mode  task 

bgg:  activated  task  ready  to  execute 

b^Q:  activated  task  or  suspended  task  requests  remote 
processor 

b -j^:  executable  task  requests  remote  processor 

b i2:  task  at  head  of  queue  bumped  by  entry  into  queue 
of  higher  priority  task 
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b94 " 

current  count  of  completed,  non-BCIU  related, 

Normal  Mode  tasks  in  the  remote  processor 

b95; 

BCIU  operation  needs  to  be  processed 

b96  * 

a  bus  message  needs  to  be  processed 

b97 " 

interrupt  has  been  processed  by  the  remote  processor 
and  BCM  in  the  remote  BCIU  can  be  unbusied 

00 

O' 

signal  that  command  was  received  or  a  message 

b99  * 

remote  processor  request  or  flag 

b  100: 

status  update  or  message 

J 

b101: 

current  status 

b102  * 

updated  status  or  message  +  status 

b103: 

status  response  or  message  +  status 

b104  * 

updated  status 

L 

b105 " 

cleared  status 

[ 

i 

b106  * 

end  of  BCM  activity  or  interrupt  has  been  processed 
by  remote  processor,  so  BCM  in  the  remote  BCIU  can 
be  unbusied 

b107 : 

acknowledge  receipt  of  command  from  bus  if  BCIU 
is  busy 

b108  ’ 

a  command  received  from  bus  needs  to  be  processed 

b109  ’ 

copy  of  message  being  processed  by  BCM  in  the  remote 

BCIU 

b110: 

the  BCM  in  the  remote  BCIU  is  busy 

blll: 

message  is  ready  to  be  transmitted 

b112 " 

bus  command  has  been  processed 

b113  * 

the  remote  processor  needs  to  take  action  in 
response  to  the  received  bus  command 

bll4: 

the  received  command  requires  no  further  action 

b115  ’ 

status  response  or  message  +  status 

( 

priority-in  queue  for  master  processor 

i 

queue  for  master  BCIU 

► 

;  f 

i 

t 
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....  .  - 

t 

i 

i  * 

Qptjl: 

rl  = 
r2  : 
r3  : 
r4  : 
r5  : 

r6  : 

r7  : 
r8  : 
r9  : 

r10  * 

rll: 
rl2 ' 

r13: 

rl4: 

rl5: 

rl6: 

r17  * 
rl8: 

r19: 

r20: 


priority-in  queue  for  remote  processor 
detect  if  executing  task  is  a  Normal  Mode  task 
choose  activated  task  or  suspended  task 
choose  executable  task 

choose  task  for  input  to  master  processor  queue 

detect  master  processor  idle  or  arrival  to  the 
queue  of  a  task  with  a  higher  priority  than  the 
task  at  the  head  of  the  queue 

detect  normal  termination  of  executing  task  or 
detect  an  interrupt  during  execution  of  a  Normal 
Mode  task 

detect  if  task  just  executed  was  Normal  Mode 

detect  if  Normal  Mode  task  execution  was  suspended 

detect  if  executed  Priviledged  Mode  or  executive 
task  generated  a  BCIU  operation 

detect  if  executed  Normal  Mode  task  generated  a 
BCIU  operation 

choose  master  BCIU  operations 

detect  if  the  master  BCIU  operation  is  to  unbusy 
the  BCM  subsequent  to  processing  a  master  processor 
interrupt 

detect  a  request  for  service 

choose  completion  of  interrupt  processing  or  status 
response  with  a  request  for  service 

choose  response  to  unbusy  the  BCM 

choose  master  processor  generated  or  bus  generated 
inputs  to  BCIU  queue 

detect  activity  requiring  the  master  processor 

choose  RT  or  remote  processor  transmission  onto 
data  bus 

choose  messages  for  transmission  on  data  bus 
route  messages  to  RT 
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*21'  route  messages  to  remote  or  master  processor 
*22:  detect  if  executing  task  is  a  Normal  Mode  task 

r2^:  choose  activated  task  or  suspended  task 

*2b:  choose  executable  task 

r2^:  choose  task  for  input  to  remote  processor  queue 

r2g:  detect  remote  processor  idle  or  arrival  to  the 

J  queue  of  a  task  with  a  higher  priority  than  the 
task  at  the  head  of  the  queue 

r2y:  detect  normal  termination  of  executing  task  or 

an  interrupt  during  execution  of  a  Normal  Mode  task 

^2^'-  detect  if  task  just  executed  was  Normal  Mode 

*2<}’  detect  if  Normal  Mode  task  execution  was  suspended 

r,Q:  detect  if  executed  Priviledged  Mode  or  executive 

task  generated  a  BCIU  operation 

r^ :  detect  if  executed  Normal  Mode  task  generated  a 

BCIU  operation 

r-j2:  choose  remote  BCIU  operations 

r^:  detect  if  the  remote  BCIU  operation  is  to  unbusy 

the  BCM  subsequent  to  processing  a  remote  processor 
interrupt 

r^:  choose  message  +  response  or  response 

roct  choose  remote  BCIU  response  or  remote  processor 
x  request 

r^g:  detect  updated  status  or  response 

r^y:  choose  cleared  status  or  updated  status 

r^gi  detect  end  of  message  processing  or  end  of  interrupt 
processing  by  the  remote  processor 


r^^:  detect  if  BCM  in  remote  BCIU  is  busy 

r#Q:  detect  if  an  input  from  the  bus  requires  further 
processing  by  the  remote  processor 


( 

} 


Some  shorthand  notation  is  used  in  the  formal  definition 


of  the  task  level  E-net  graph.  The  symbol  -  in  a  transition 
declaration  is  used  whenever  the  function  of  the  transition 
is  as  follows: 


1)  T  -  transition:  The  transition  firing  moves  the 

unaltered  token  on  the  input  location 
to  the  output  location. 

2)  F  -  transition:  When  the  transition  fired,  identical 

copies  of  the  token  on  the  input 
location  are  placed  on  both  output 
locations . 

3)  J  -  transition:  When  the  transition  fires,  the 

attributes  of  the  token  placed  on  the 
output  location  are  obtained  by  sum¬ 
ming  the  corresponding  attributes  of 
the  tokens  on  the  two  input  locations. 

4)  X  -  transition:  When  the  transition  fires,  the  token 

placed  on  the  selected  output  location 
is  the  token  from  the  input  location. 

5)  Y  -  transition:  When  the  transition  fires,  the  token 

placed  on  the  output  location  is  the 
token  from  the  selected  input  location. 


When  an  attribute  token  K[m]  is  transferred  from  location 
bi[m]  to  bj[m]  without  changing  the  values  of  any  attribute, 
the  transfer  is  denoted 

M(b j [m]  ):=  MCb^m] ) . 

When  any  attribute  values  are  changed  during  the  transfer  (as 
specified  by  the  transition  procedure),  the  transfer  is  denoted 


M(bj(n))  :=  MCb^Cn))  ,  1  <  n  <  m 

for  each  token  attribute  value  changed.  Only  the  attribute 
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values  which  are  changed  are  individually  notated  in  the 
transition  declaration.  T  is  the  shorthand  notation  for  the 
boolean  value  "true"  when  T  appears  in  a  transition  procedure. 
Time  is  in  milliseconds. 

The  formal  definition  of  the  E-net  in  Figure  18  is: 

E  =  (L,P ,R,A) 

R  =  (r1,r2,...,r40} 

P  =  (bn[l],  b52[8],  b55[8],  b69>U  R 

L  =  {b^[l]j  b2 [ 8 ] ,  bg [ 1 ] ,  b4 [ 1 ]  ,  bg,  bg[8],  by ,  bg,  bg[l], 

b^Q  [  1  ]  j  b^  [  8  ] , . . .  ,  bl7[8],  b^g ,  .  .  .  ,  b2  g }  b2^[8],...j 

bggtS],  bgg,  b^Q,  b^^[8],  b^2 ,  b^g,  b^^[8],  b^g,  b^g , 
b47[8],  b^g ,  b4g[8],...,  bgg [ 8 ] ,  bgg[l],  bgQ[8], 

b61U],  bg2  [  1  ] ,  bgg ,  bg4[  8  ]  ,  b&5,  bgg,  bgy[l],  b6g[l], 
bgg[  8 ]»•••»  b75 [ 8 ] ,  byg , . . . ,  bg^ ,  bg2[8],...,  bgg[8], 

b97>  bgg[ 8 ] , . . . ,  b1Q5 [ 8 ] ,  b106,  b107[8],  b10g[8], 

b109 1  8  ^  »  b110’  blll  t 8  ^  >  b112  ^  8  ^  5  b113  ^ 8  ^ 5  bll4}^  P 
A  =  (a^ ,  a2 , . . . ,  ag2 } 

al  =  <F<b5o[8^  bi 1 1 1  j  b2[8]),  0, 

[T  -  (M(b2[8])  :=  M(b50[8] ) ; 

M(bt [ 1 ] )  :=  1 j) ] ) 

a2  =  (J(b3[l],  bt [ 1 ] ,  b4[l]),  0,  -) 


124 


a3  =  (F(b2[8],  b5,  b6[8]),  0, 

[T  -  (M(b5)  :=  1; 

M(b6[8]  :=  M(b2[8] )) ] ) 
a4  =  (T(b4[l],  b3[l])f  0,  -) 
a5  =  (X(r^ ,  b^,  by,  bg )  >  (OjO)  >  — ) 
a6  =  (J(b9[l] ,  b?,  b1Q[ 1 ] )  ,  0, 

[T  *  (M(b10(a))  :=  M(b9(l))  +  1)]) 


a7  = 

(T(bio 

[1],  bg[l]) 

,  o, 

-) 

a8  = 

(  Y  (  r  2  » 

t>11  [  8  ]  , 

b2gt  8] , 

b12[S]) 

,  (0,0) 

a9  = 

(Y(r3, 

b12[8]. 

b14[8], 

b13[8]) 

,  (0,0) 

10  = 

(Y(r4> 

b6[8], 

b13 

[8], 

Qm[S])  , 

(0,0)  , 

11  = 

(X(r5, 

QJ8], 

b15 

[8], 

bl4[8] )  3 

,  (0,0) 

12  = 

( F ( bl 5 

[8],  b16 

[8] 

’  b17 

[8])  ,  0, 

-) 

13  “ 

( J ( bl 8 

•  bl«t8' 

,  b 

19)  > 

0, 

[T  -  (M(b19)  :=  1; 


END  TASK(l)  :=  CLOCK  +  M(b16(4)))]) 
a^4  =  (T(b^9»  b^g)  5  — ^ 

ai5  =  ^T^b20 *  b21^  »  °» 

a1()  =  ^^b21*  b20’  b22 ^ 

a^7  =  (Y(rg,  b22  »  b8 »  b23^  *  (®»®)  >  “) 
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(J(b23’  bi7^ »  b2U[8])  ’  (0‘0)  » 

[(END  TASK(l)  >  CLOCK)  - 

(M(b24(4))  :=  END  TASK(l)  -  CLOCK; 
M(b24(5))  :=  M(b17(5))  +  M(b1?(4)) 
-M(b24(4)); 

M(b24(i))  :=  M(b1?(i))  , 


i 

=  1,2, 3, 6, 7, 

8): 

T  * 

(M(b 

24(5>>  : 

=  M(b1?(4))  + 

M(b17(5) ) ; 

M(b 

24(4) )  : 

=  0; 

M(b 

24(0)  : 

=  M(b1?(i)), 

i 

=  1,2, 3, 6, 7, 8)]) 

a19  = 

(X(r?, 

b24 

[8],  b25 

[83,  b26[8]) 

,  (0,0)  ,  -) 

a20  = 

(X(rg, 

b26 

[8],  b27 

[8],  b28[8)) 

,  (0,0)  ,  -) 

a21  = 

(X(r9, 

b25 

[8],  b29 

[8],  b3Q[83) 

,  (0,0)  ,  -) 

a22  = 

( x( r 10 

,  b27 [ 8 ] ,  b3^[ 8] ,  b32 [ 8 ] ) 

,  (0,0)  ,  - 

a23  = 

(J(t>33 

[8), 

b29 [ 8 ] , 

b34[8] )  ,  0, 

-) 

a24  = 

(T(b34 

[8], 

b33[8]) 

,  0,  -) 

a25  = 

(J(b32 

[8], 

b36[8), 

b35 [ 8 3 )  ,  0 , 

-) 

a26  = 

(T(b35 

[8], 

b36[8]> 

,  0,  -) 

a27  —  »  b30^®^’  t>2^['8],  b^7[8])  ,  (0,0)  ,  -) 

a28  =  ^^ri2*  b37^®^ »  ^3^)  ,  (0,0)  , 

[M(r12)  =  0  (M(b38[8])  :=  M(b37[8])): 

T  -  (M(b39)  :=  1)]) 


t 


a29  =  (X(ri3>  b57[8],  b40[8],  b4l[8])  ,  (0,0) 
[M(r13)  =  0  (M(b4Q)  :=  1): 

T  -  (M(b4l[8])  :=  M(b5?[8] )) ] ) 

a30  =  (Y(rl4’  b39 5  b4o>  b42)  >  (0,0)  ,  -) 
a31  =  ^F^b4l^8^’  b43>  b44 [ 8 ] )  ,  0, 

[T  -  (M(b43)  :=  1; 

M(b44[8])  :  =  M(b4l[8]))]) 

a32  =  (y(ri5>  b42»  b43>  b45)  >  (0,0)  ,  -) 
a33  =  ( J(b48 »  b45 ’  b46^  »  °» 

a34  =  (Y(r16>  b44[8]>  b38[8^  Qj8!)  »  (0,0)  , 
a35  =  (J(b4g,  Qn[8],  b4y [ 8 ] )  ,  0, 

[T  -  (M(b4y[8])  :  =  M(b46[8]))]) 

a36  =  (F(b47[8] ’  b48 5  b49t 8 1 >  ,  0, 

[T  -  (M(b49[8] )  :=  M(b4?[8] ) ; 

M(b4g)  :=  l)]) 

a37  =  (X(ri7’  b49[8],  b5^[8],  b51[8] )  ,  (1,2)  , 
[M(r1?)  =  0  (M(b50(l))  :=  1; 

M(b50(2))  :=  0; 

M(b5Q(3))  :=  1; 

M(b5Q(4))  :=  2; 

M(b5Q(5))  :=  0); 

M(b50(6))  :=  M(b49(6)); 
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M(b5Q(7))  :=  M(b49(7)); 
M(b50(8))  :=  M(b49(8))  +  1) 
T  -  (M(b50(6))  :=  M(b49(6)); 

M(b5Q(8))  :=  2; 

M(b5Q(i))  :=  0, 


i  =  1,2,3 

,4,5,7)]) 

(Y(r18> 

b115C8]  , 

b52[8]’  b53t8l> 

,  (0,0)  , 

(Y(r19, 

b53[8]  , 

b51 ^ 8  ^ »  b54[ 8 ] )  , 

(0,0)  , 

(X(r20, 

bs4[ 8 ] , 

b55[8],  b56[8] )  , 

(0,0)  , 

(X  (r2l 

j  b3g [ 8 ] , 

[ 8 ]  ,  b^g [ 8 ] ) 

,  (0,0)  , 

(F(bl13 

[8],  b^gfl],  bgQ[8])  ,  0, 

[T  -  (M(b59[l]> 

:=  1; 

M(b6Q[8])  :=  M(bU3[8]))]) 
(J(b6i[l],  bg2[l]),  0,  -) 

^F^b66^8^’  b63’  5  °> 

[T  -k  (M(b63)  :=  1; 

M(b64[8])  :=  M(b60[8]))]) 

(T(b62[l],  b61[l])  ,  0,  -) 

(X(r22,b63,  b65,  b66)  ,  0,  -) 

(J(bg7[l],  bg5,  b6g[l],  0, 

[T  +  <M<b68(1))  :=  M(b67(l))  +  1)]) 


II 

00 

■sl¬ 

ed 

<T<b68 

[1],  b67[l])  ,  0 

,  -) 

a49  = 

(Y)r23 

»  b69^8^J  b86^ 

,  b7or  83) 

,  (0,0)  , 

- 

a50  = 

(Y(r24 

»  b7o^ 8  ^  5  b72  ^ ® 1 

,  b?1 [ 8 ] ) 

,  (0,0), 

-) 

a51  = 

( Y(r25 

»  b64.[8]  ,  b7^[8] 

,  Qp  C  8 ] )  , 

(0,0)  , 

-) 

a52  " 

(X(r26 

,  Qp [ 8 ] ,  b?3 [ 8 ] , 

b72[8])  , 

(0,0)  , 

-) 

a53  = 

(F(b?3l 

f8],b74[8],  b75[8])  ,  0,  - 

) 

a54  = 

(J(b?6! 

>  b74 [ 8 ] ,  b77 )  , 

o, 

[T  -  (M(b1?)  :=  1; 


END  TASK(2 )  :=  CLOCK  +  M(b?4(4)))]) 
a55  =  (T(b77*  b76)  >  0»  -) 

a56  =  (^(b  78  b79^  s  0,  “) 

a57  =  ^F^b79>  b78>  bgo)  >  0,  -) 

a58  =  (Y(r27’  b80 ’  b66 *  b8l*  »  (0’°>  »  -) 

a59  =  (j(b8l’  b75 C 8 ] ,  b82 [ 8 ] )  ,  (0,0)  , 

[(END  TASK(2)  >  CLOCK)  ♦ 

(M(b82(4))  :=  END  TASK(2)  -  CLOCK; 

M(b82(5))  :=  M(b?5(5))  +  M(b?7(4)) 
-M(bg2(4)); 

M(b82(i))  :=  M(b?5(i))  , 

i  =  1,2,3, 6, 7, 8): 

T  -  (M(b82(5) )  :=  M(b?5(4))  +  M(b75(5)); 
M(bg2(4))  :=  0; 

M(b82(l))  :=  M(b75(i))  , 

i  =  1,2, 3,6, 7, 8)]) 
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l60  = 

(X(r2s» 

bg2[  8]  , 

bg3[ 8] , 

00 

00 

x> 

,  (0,0) 

,  -) 

61  = 

(X(r29, 

bg4[ 8^  * 

bg3C 8 1 > 

b86 [ 8 1 ) 

,  (0,0) 

,  -) 

62  3 

( X  ( r  3q  , 

b83[8], 

bg7[8] , 

bgg[8] ) 

,  (0,0) 

,  -) 

63  3 

(X(r31 » 

b85[8], 

bgg[  ® ] » 

b90[8]) 

,  (0,0) 

,  -) 

a64  ~  b87[8],  b92[8])  ,  0,  -) 

a65  3  (T(b42[8]>  b91[8])  ,  0,  -) 
a66  3  <JO>90[8],  b94[8],  b93[8])  ,  0,  -) 
a67  =  CT(b93f 8] ,  b94]8])9  0,  -) 

a68  3  (Y(r32»  bgg[8],  b89[8],  b93[8])  ,  (0,0)  ,  -) 
a69  3  ^^r33*  b95^®]»  b9g[8],  b97)  ,  (0,0)  , 

[M(r33>  “  0  -  (M(b96[8])  :=  M(b95[8])): 

T  -  (M(b9?)  :=  1)]) 

a70  =  (Y(r34’  b107[8]>  blU[8l’  b98[8])  »  (0,0)  > 

[M(b107[8])  *  0  *  CM(b98(7) )  :=  l; 

M(b9g(i))  :  =  M(b10?(i))  , 

i  =  1 , . . . ,6 ,8) : 

T  -  (M(b98(8))  :=  M(b111(8)); 

M(b98(i))  :=  0  ,  1  -  i  -  7)]) 

a71  3  ^^b96^8^’  r38»  b99  [  8  ] )  ,  0, 

[T  +  (M(r3g)  :=  1; 

M(b99(7))  :=  M(b96(7)); 

M(b99(i))  :»  0  ,  1  =  1,...,  6,8)]) 
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a72  -  (Y(R35,  bg9[8],  bgg[ 8] ,  b10Q[ 8 ] )  ,  (0,0)  ,  -) 

a73  =  ^J^b100^8^  b101^’  b102^8^  »  °»  “) 

a74  =  ^X^r36»  b102 ^ 8 ^  »  b103 ^ ^ »  bl04^8^  >  (°»°)  »  -) 
a75  "  (F(b103[8],  bn5[8],  b105[8])  ,  0, 

[T  -  (M(b105(l))  :=  0,  1  -  i  -  8; 

M(b115[8])  :=  M(b1Q3[8]))]) 

a76  =  (Y(r37’  b105[8]’  b104[8]»  b101[8])  >  (°»°)  .  -) 
a77  =  ^Y^r38  *  b97  *  b114 *  b106^  »  °» 
a78  =  ^J^bl06’  b110’  r39^  »  °>  *“) 

a79  =  (x^r39>  ^57^  8] ,  b1Q7[8],  b10g[8])  ,  (0,0)  ,  -) 

a80  =  (F^bl08^8^5  b109^8^*  b110^  *  0> 

[T  -  <M(bU0)  :=  1; 

M(b1Q9[8])  :=  M(b10g[8]))]) 

a81  =  (F(blog[8],  bm[8],  bm[8])  ,  0, 

[T  ->  (M(blu(8))  :  =  M(b1Q9(8)); 

M(bUl(i))  :=  0  ,  1  £  t  $  7; 

M(b112(8))  :=  M(b1Q9(8))  +  2; 

M(bu2(i))  :=  M(b1Q9(8))  ,  1  <  i  <  7)]) 


i 

i 


( 
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a82  =  ^X^r40»  bil2^8^’  b113^8^  *  b114^  »  (°»°)  > 
[M(r40)  -  0  -  (M(blU)  :=  1): 


T  -  (M(b113(D) 

:=  l; 

M(b1130)) 

:=  i; 

M(b113(4)> 

:=  i; 

M(b113(8)) 

:=  M(b112(8)); 

M(b113(i» 

:=  0  ,  i  =  2, 5, 6,7)]) 

{END  TASK[ 2 ]  ,  CLOCK} 

{ ’•'(r^)  j  •  •  •  j  ^ ( ^4q) ) 

=  r1  :  [M(b17(2)> 

=  1  -  M(r1)  :=  1: 

T  ♦  M(r1)  :=  0] 

^(r2)  -  r2  :  [T  M(r2) 

:=  1] 

»(r3)  =  r3  :  [T  +  M(r3> 

:=  1] 

y(t4)  »  f4  :  [T  +  M(r4) 

:=  0] 

'F(r^)  =  :  [M(Qm_^  (3))  <  M(C^(3)) 

M(r5) 

:=  1: 

M(bl7[ 8] ) 

4  0  M(r5)  :=  0] 

’*'(rg)  =  r6  :  [M(bg)  =  1 

-  M(r6)  :=  is 

<(M(b17[8] )  4  0)  ((END  TASK(l)  -  CLOCK) 

(M(b1?(2))  -  1  M(b17(3)) 

S  M(Qm(3))))  -  M(rfi)  :=  0] 
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<r(r7)  =  r7  :[M(b24(2))  =  1  -  M(r?)  :=  1: 

T  -  M(ry)  :=  0] 

*(rg)  -  rg  :[M(b26(4))  =*  0  -  M(rg)  :=  0: 

T  -  M(rg)  :=  1] 

»(r9)  =  r9  :[M(b25(6))  >  0  M(b25(l))  =  1 

♦  M(rg)  :=  1: 

T  -  M(rg)  :=  0] 

f (rio)  =  *10  :[M(b27(6))  >  0  M(b27(l))  =  1 

+  M(r10)  :=  0: 

T  -  M(r10)  :=  1] 

^  (^11  =  rll  :^T  ■“ 

y (f 12 )  =  f12  :[M(b^7(l))  =  1  +  M(r12)  ’=  1: 

T  -  M(r12)  :=  0] 

y )  =  r13  :  [;M(b5g(7)>  >  0  >  M(r13)  :=  1: 
T  *  M(r13)  :=  0] 


’(r14> 

tH 

Vi 

II 

:  [  T  ♦ 

M(ru)  :  = 

0] 

'(r15) 

"  r15 

:  T  + 

M(r15)  := 

0] 

t  (r  ) 

=  r 

:  [T  - 

M(r_  ) 

1] 

16 

16 

16 

T (r17> 

"  r17 

:  [M  (b^g(6))  >  O' 

♦  M(r^7) 

T  -  M(r17)  :=  0] 
▼(rlg)  =  r18  :  *  M^r18^  := 


j 


y(f^g)  =  r^g  •  [T  -*•  M(r^g)  t=  0] 

y(r2o^  =  r20  *  ^ ^  '*’  *^r20^  *= 

y(r2i)  =  r21  :[M(b56<6))  >  0  M(b56(7>)  =  0 

-  M(r21)  :=  0: 

T  -  M(r21)  :=  1] 

y(r22)  =  r22  :[M(b?5(2))  =  1  M(r22)  :=  1: 

T  -  M(r22)  :=  0] 
y(r23)  =  r23  :[T  +  M(r23)  := 

^ ^r24)  ~  r24  *  t ^(r^)  i=  1] 

Y(r25)  =  r25  :  [T  *  M(r25)  :=  0] 

v(r26)  =  r26  :tM<Vl(3))  <  M<Qp(3>> 

♦  M(r26>  1: 

M(b75[8]  +  0  M(r26)  :=  0] 

y(r27)  =  r27  :[M(b66)  >  1  ♦  M(r27)  :=  Is 

((M(b1?[8])  +  0)  ((END  TASK(2)  $  CLOCK) 

(M(b75(2))  =  1  M(b1?(3)) 

5  M(Qp( 3) ) ) )  -  M(r2?)  :=  0] 
t(r28)  =  r28  : t M(bg2 ( 2 ) )  =  1  +  M(r2g)  :=  1: 

T  -  M(r28)  :=  0]- 


'f(r29)  =  r2g  :[M(bg4(4))  =  0  -  M(rzg)  :«  0: 
T  -  M(r29)  :  =  1] 
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v(r30)  =  r30  :tM<b83(6)  >  0  M<b83(1))  =  1 

-  M(r30)  :=  1" 


H'(r3l) 


T  *  M(r3Q)  :=  0] 

=  r,.  :[M(b-c(6))  >  0  M(b«e(l))  =  1 


-  M(r31)  :=  0: 


i'(r~0)  = 


T  *  M(r31)  :=  1] 
:  [T  -  M(r„)  :=  0] 


,(r33> 


r33:[M(b95(l))  "  1  *  M(r33)  1: 


T 

*  M(r33) 

:=  0] 

,<r34) 

"  r34 

:  [T 

♦  M(r34) 

:=  0] 

',<r35) 

=  r35 

:  [T 

+  M(r35) 

:=  0] 

»(rJ7) 

=  r37 

:  [T 

-  M(r37) 

:=  0] 

»(r38) 

=  r38 

:[T 

♦  M(r3g) 

:=  0] 

*(r40> 


=  r/-n  >  1  -  M(r,n)  :  =  0: 


T  >  M(r4Q)  :  =  1] 


vr*  ,  k.-  :  •- 

*;■ 

'f/'r-  y. V*-  .  -,s 


■  -y*  * 

•fi. . 


*  •  ^  1 


Appendix  D:  Token  Flow  in  the 
Task  Level  E-Net  Graph  of  the  DAIS 


An  interpretation  of  the  E-net  graph  in  Figure  18  is 
begun  by  assigning  an  initial  marking,  Mq,  to  the  net  and 
initializing  the  environment  variable  CLOCK  to  zero.  It  is 
assumed  that  the  net  environment  will:  a)  update  CLOCK  when 
no  transitions  are  enabled  and  b)  place  tokens  on  locations 


b^  and  « 


Let  Mq  be  defined  as  follows: 


M(b3)  =  M(b9)  =  M(b61)  =  M(b67)  =  L [ 1 ] ,  L(l)  =  0; 

M(b33)  =  M(b36)  =  M(b91)  =  M(b94)  =  M(b101)  =  J[8] , 

where  J(i)  =  0  ,  l-i-8  ; 

M(blg)  =  M(b21)  =  M(b22)  =  M(b46)  =  M(b?6)  =  M(b?9) 

=  M(bg0)  =  M(r39)  =  1  ;  M(r36)  =  0  ; 

M(b j)  =0  ,  1  ^  j  <  U5  ,  j  ^  3,  9,  18,  21,  22,  33, 

36,  46,  61,  67,  76, 
79,  80,  91,  94,  101  ; 

M(r a )  =  «  ,  1  4  t,  4  40  ,  i  4  36,  39  . 


Given  Mq  and  CLOCK  =  0  ,  let  the  environment  place  token 

K[8]  on  location  ,  where 

K(l)  =  K(2)  =  K( 5)  =  K(7)  =  K(8)  =  0  ; 

K( 3)  =  2  ; 

K(4)  =  4  ; 

K(6)  =  1  . 
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The  following  net  operations  will  take  place: 


ag  fires, 

M(b12) 

=  K[8] 

,  M(bu)  =  0  ; 

ag  fires, 

M(b13) 

=  K[8] 

,  M(b12)  =  0  ; 

a10  fires> 

M(Qm) 

=  K[  8] 

,  M(b13)  =  0  ; 

a n  fires, 

M(b15) 

=  K[8] 

,  M(Q  m )  =  0  ; 

a12  fires, 

M(b16) 

=  M(b1?)  =  K [ 8 ]  ,  M(b15)  =  0 

fires, 

M(bJ9> 

=  K[8) 

,  M(blg)  =  M(b18)  =  0 

al4  fires, 

M(bt8) 

=  K[8] 

,  M(b19)  =  0  ; 

CLOCK  =  4 

J 

a17  fires. 

M(b22) 

=  o  , 

M(b23)  =  i  ; 

a16 

M(b22) 

=  M(b2Q)  =  1  ,  M(b21)  =  0  ; 

a15  fires, 

M(b21) 

=  1  , 

M(b20)  =  0  ; 

a18  fires. 

M(b23) 

-  o  , 

M(biy)  =  0  , 

K(l)  = 

K(2)  = 

K(4)  =  K(7)  =  K(8)  =  0  , 

K(3)  = 

2,  K(5) 

=  4,  K(6)  =  1, 

M(b23) 

=  "updated”  K[8]  ; 

aig  fires, 

M(b25) 

-  K[8] 

,  M(b24)  =  0  ; 

&2i  fires. 

M(|0  ) 

=  K[8] 

,  M(b25)  =  0  ; 

fires. 

M(b37) 

=  K[  8] 

,  M(b3Q)  -  0  ; 
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a28  fires, 

M(b38)  =  K[ 8] 

,  M(b3?)  =  0  ; 

a34  fires, 

MCQh)  =  K[ 8 ] 

,  M(b38)  =  0  ; 

a^^  fires, 

M(b4?)  =  K[ 8 ] 

>  MCQh)  =  0  ,  M(b46)  =  0  ; 

CLOCK  =  6 

• 

) 

a36  fires, 

M(b47)  =  0  , 

M(b48)  =  1  , 

K(l)  =  K(2)  = 

K(4)  =  K(7)  =  0  , 

K(3)  =  K(8)  = 

2  ,  K(5)  =  4  ,  K(6)  =  1  , 

M(b49)  =  "updated"  K[8]  ; 

a37  fires,  M(b49)  =  0  ,  K(6)  =  1  ,  K(8)  =  2  , 

K(l)  =  K(2)  =  K(3)  =  K(4)  =  K(5)  =  K(7)  =  0  , 
M(b51)  =  "updated"  K[8]  ; 


a39 

fires , 

MO>54) 

=  K[83 

,  M(b51)  =  0  ; 

a40 

fires , 

M(b56) 

=  K[8] 

,  M(b54)  =  0  ; 

a4l 

fires , 

M(b57) 

=  K[83 

,  M(b56)  =  0  ; 

a79 

fires , 

M^b108^ 

=  K[83 

,  M(b57)  =  0  ,  M(r4l) 

a80 

fires , 

M^b109^ 

=  K[83 

*  M^b110^  =  1  ’  M^b108^ 

00 

fires , 

M(b112) 

=  k[83 

,  M(b^Q9)  =0  , 

K'(i)  = 

0  ,  1 

5  i  -  7  ,  K"(8)  =  2  ; 

M<blll> 

=  K'[8] 

! 

o 

« 

fires , 

M(b98)  = 

=  K"[83 

»  M(blu) =  °  » 

a72 

fires , 

M^b100^ 

=  K'[83 

>  M(b98)  =0  j 

a73 

fires , 

M(biQ2) 

=  K'[83 

,  M(b100)  =  M(b101)  =  0 
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a74 

fires , 

M<b103>  *  K 

'[8]  , 

M(b102)  -  0  ; 

a75 

fires , 

M(bU5>  "  K 

'[8]  , 

H(b103)  -  0  , 

M<b105(i» 

=  0 

9 

1  ^ 

i  -  8  ; 

a76 

fires , 

M<bioi>  ■  M(W 

) 

M(bi05)  =  °  ; 

a38 

fires , 

M(b53)  =  K" 

[8] 

9 

M(b 

115)  =  0  ; 

a39 

fires , 

M(b54)  =  K' 

[8] 

9 

M(b 

53)  =  0  ; 

a40 

fires , 

M(b56)  =  K' 

[8] 

9 

M(b 

54)  =  0  ; 

a41 

fires , 

M(b5g)  =  K' 

[8] 

9 

M(b 

56)  =  0  ; 

a29 

fires , 

M(b4Q)  -  1 

9 

M(b 

58  ^ 

=  0  ; 

a30 

fires , 

M(b42)  =  1 

9 

M(b 

42^ 

=  0  ; 

a32 

fires , 

M(b45)  =  1 

9 

M(b 

42  ^ 

=  0  ; 

a33 

fires , 

M(b46)  -  1 

9 

M(b 

45^ 

=  M(b48)  =  0  ; 

CLOCK  =  6 

• 

9 

CM 

00 

fires , 

M(bn4)  =  1 

9 

M(b112 

)  =  0  ; 

a77 

fires , 

M(bi06)  = 

1 

, 

M(bn4)  =  0  ; 

00 

cS 

fires , 

M(r3g)  =  1 

) 

M(b 

106) 

=  0  . 

The  net  is  now  inactive  until  the  environment  places  another 
token  on  or  bg9.  The  net  marking  now  is  identical  to  MQ. 
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